Yeah, I can respect everything you said here, and more or less agree. By the way, what is "coverity"? Is it related to "coverage"? I tried to look up a definition some time back and came up dry.
-mrt Original Message From: Jon Trulson Sent: Wednesday, August 1, 2018 12:09 To: Matthew R. Trower Cc: Marcin Cieslak; cdesktopenv-devel@lists.sourceforge.net Subject: Re: [cdesktopenv-devel] Docbook On 07/31/2018 08:47 PM, Matthew R. Trower wrote: > Jon Trulson <j...@radscan.com> writes: > >> On 07/31/2018 07:53 PM, Matthew R. Trower wrote: >>> Jon Trulson <j...@radscan.com> writes: >>> >>>> Not a clue. I think ultimately we would want it to generate HTML and >>>> just use a web browser for both help and the guides. >>> >>> I'd really hate to see that. >>> >>> * DtInfo is part of CDE. >>> >>> * DtInfo (like all of CDE) is very lightweight. >>> >>> * DtInfo provides index and search capabilities (this is a primary >>> strength of DocBook). Doesn't that sort of go out the window with >>> HTML? >>> >> >> Well, converting to docbook XML (not html) should preserve all of that >> functionality actually. With that, we could generate HTML if we >> wanted, or PDF's of the guides, or a variety of other formats. But I >> don't know what the cde-specific software like dthelp and dtinfo are >> actually doing. >> >> There's the format and manipulation of the documentation itself - this >> is what I'm talking about. > > Sure, I'm with you so far (on DocBook XML). But you mentioned > generating HTML and just using a web browser. Are you suggesting that > we throw out DtInfo and friends and use a web browser (e.g. Firefox, > Dillo) instead? Or simply that we could generate additional formats > (e.g. HTML) for convenience? Or, are you suggesting that an HTML > renderer be embedded into DtInfo? > > I see below that you probably don't want to throw it out, so I guess I > misunderstood you here (on HTML and browsers). What did you mean? > No, I don't want to throw it out, though in the end, we may want to alter how it works internally - say using some sort of html widget for display and navigation rather than the custom parser/renderer that appears to be present now. But again, I do not know enough about how the internals work to do anything other than speculate at this time. > >> I'm not sure what you mean by out-of-tree technology. I do not think >> trying to maintain ancient copies of code (nsgmls, et. al) is a viable >> solution. No one maintains it. > > Well, I guess I just don't think the situation is so dire. We're here > in 2018, and it's still chugging along. I don't see any tickets about > it. Is it broken? > > I'm not really suggesting that the ideal route is to keep our in-tree > toolchain forever, though. The statement about in-tree, out-of-tree, > modern, etc came about as a result of general feelings about the tech > industry's push for newer and shinier, even at the cost of (in my eyes) > quality. I feel especially keenly about it in heritage projects like > this. I think that balance is important, and am conservative about > ripping out existing tech in favor of new. I'm having a hard time > putting my full thoughts on this to digital paper right now, and it's > probably not worth it as I think I may have misunderstood you. > > Also, I suspect you've learned a thing or two in your career about > bit-rot and maintainership that I should probably defer to. =) > My issue is in duplicating existing software with older, unmaintained versions. I don't like that. It's extra maintenance and a source of potential trouble (security issues, coverity issues, even compiler warning issues.) Time and development resources for working on CDE are restricted - therefore the less we have to worry about, the better off we will be in terms of being able to deliver something usable in a modern environment with the resources we have... Also, I don't think the future of CDE is in keeping things exactly as they are -- the world has moved on from some of the technologies that were brand new when CDE was under active development. I don't think it is reasonable, or feasible to keep everything exactly as it was in 1995. So, no I don't want to remove dtinfo and dthelp, but updating them to something based on modern standards and practices is not a bad goal either. Hell, some of this stuff was developed before the Internet was even a thing. And some of the code is really bad. Preserving and maintaining that is not long term a goal, it can't be. > >> I do suggest we offload the utilities portion (like osgmls) to OS >> versions and not keep bit-rotting versions in our tree. > > I don't have a problem with using system opensp. I don't see that > affecting anybody, really, so I'm happy to reduce our code footprint. > >> I am also for converting the current older SGML document formats to >> XML and docbook 5. As to how that affects dthelp/dtinfo, I just don't >> know at this time. > > Thats probably reasonable enough, if not pressing (not that you > suggested it was). I'm curious about SGML (a scheme dialect? I'm with > the editor (esr?) on this one), but it seems the DocBook community > prefers XML (considered lightweight in this context? Oh my). In > addition to the newer tooling, it might make onboarding easier for > revising / adding documentation to the project. Honestly, I suspect XML > probably *is* more reasonable for documentation anyway. > Yes, there's a lot to learn here. That's another problem - trying to maintain something you don't really understand :) -- Jon Trulson "Fire all weapons and open a hailing frequency for my victory yodle." - Zapp Brannigan ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
