[EMAIL PROTECTED] (Marco Budde) writes: > APH> Putting the same info, shadowed in multiple places, is exactly what > APH> dhelp does. > > ??? That#s wrong.
You must not understand my terminology. The fact that you are constructing a database out of the metadata, in the current dhelp, means that you are "shadowing", or "keeping another copy" of the metadata itself. This leads to bugs and problems. It's a fact of software design. My dream is to have a single fast-access method of accessing metadata that works for *all* display systems, but that might be a pipe dream. Read that as, "I'm not planning on having it in the next major release of install-docs". > APH> I propose to eliminate that and adopt a central document > APH> store, rather than having display systems read docreg files. > > No, we#ve discussed this already. It should be possible to use dhelp on a > non Debian system. And I need special organized databases. You can add an > API to doc-base, no question. But (a) I don#t need it and (b) this would > be a doc-base project and shouldn#t be part of the file format standard. Sure. Of course, you realize the file format standard is just a chapter of the broader Debian Metadata standard. You seem a bit confused on this point. > APH> crucial requirement for debugging, and dhelp contains a number of > APH> critical bugs because > > Nonsense, there#s no real bug in dhelp. Please tell me the number of the > bug report. Bug#21361. If I did a security audit on dhelp, I'm sure I could find a number of overflow conditions and bugs in the system could be triggered by malicious dhelp files. Since dhelp_parse -r will readily gobble these, and since root usually runs this, the current situation is a little troubling. > APH> (a) it's got it's own document store, which > APH> isn't well debugged, and > > What an argument against a file format :(! Are you kidding? No, an argument against data shadowing implemented in each and every display system. Again, it's worrying but I don't think we're going to solve it this time around, but you should recognize the flaws. > APH> We propose to resolve relative links against a "path" of > APH> /usr/share/doc:/usr/doc:http://www.debian.org/doc . > > That#s a very bad solution. This is (a) very slow (200% slower) Granted. > and (b) > how should I resolve something against http://www.debian.org/doc? And in > Germany and a lot of other countries a Internet connection is very > expensive. You're totally befuddled on this point, but it's understandable. I'll summarize my position on this issue in the next post. > Ok connections between translations won#t work. But this is not a real > problem. And as mentioned yesterday, there#re other cases where we will > have the same problems. > Maybe it#s not a good idea, to use the filename as identifier. Our old > solution (doc-base) hasn#t got this problem. Very true. But it uses a "surrogate key" system and has no way to resolve namespace conflicts. Each package should have its own name space; we already have gloabally unique package names. -- .....A. P. [EMAIL PROTECTED]<URL:http://www.onShore.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
