Subject: Re: future of dhelp - msg#00034

List: linux.debian.devel.documentation

Date: Prev Next Index Thread: Prev Next Index

Daniel Nouri <daniel.nouri@xxxxxxxxxxxx> writes:

> Some ideas that I'd like to be shared and weighed out by
> you:
>
> If we decide to ask the program for version compatibility,
> then we need to at least back our new file versions
> through debian package version dependencies. For example,
> dhelp in the current stable branch does not support version
> querying at all. Or some new package system decides to
> support only from version 2 upwards.
> What I want to say is that different file versions (as
> discussed by you) involve different debian package
> (version) dependencies already.
> So why not drop the ".../hooks/program version" idea for
> the sake of package interdependency, solely?

See, this won't work. Suppose I have doc-base version 0.9.0 which is
first cut with the hooks. So the dhelp that provides the hook depends
on doc-base >= 0.9.0. So far so good.

But suddenly, there's doc-base 0.10.0 which adds optional
internationalized doc-registration fields. Ok, suppose your script
can handle/ignore fields it doesn't understand. But suddenly its
choking because we're shooting it UTF8 source.

I could deal with this by having doc-base conflict with the current
dhelp which doesn't handle UTF8 docreg files -- but I don't know that
the next one will support it. And moreover, suddenly dhelp
registration is utterly broken. *Unless* I'm able to provide data in
a backward-compatable way until dhelp hooks are updated.

You see why having versioning built in has benefits, despite a littel
complexity.

> When packages register with doc-base through 'install-docs
> -i ...', they do so one by one.

No, one of the changes will be a simple top-level looping so it can do
many at once.

--
...Adam Di Carlo...<adam@xxxxxxxxxxxx>.......<URL:http://www.onshored.com/>

Was this page helpful?

Thread at a glance:

Previous Message by Date: click to view message preview

Re: future of dhelp

Daniel Nouri <daniel.nouri@xxxxxxxxxxxx> writes: > I agree as well. To overcome the problem of a file seperator, I'd > suggest to call the program once for every action (install, remove, > upgrade). That won't scale up to well. Think of the update-menus example -- I don't want to call that for each and every document. > > Sounds good and flexible IMHO. Maybe doc-base can provide a parser > > class for it as well to avoid that every program needs to reinvent > > the wheel. > > I don't see how a parser (that would be written in, say, Perl) fits > into my program as a module. Communication over stdin? A parser > for everyone would be nice but how could it be done cleanly? If we're concerned about a parser, I think the best thing would be to provide an XML data interchange format. XML parsers are cheap and plentiful. Or is that too much? -- ...Adam Di Carlo...<adam@xxxxxxxxxxxx>.......<URL:http://www.onshored.com/>

Next Message by Date: click to view message preview

Re: future of dhelp

On 22 Feb 2003 13:52:44 -0600 Adam DiCarlo <adam@xxxxxxxxxxxx> wrote: > Daniel Nouri <daniel.nouri@xxxxxxxxxxxx> writes: > > > I agree as well. To overcome the problem of a file seperator, I'd > > suggest to call the program once for every action (install, remove, > > upgrade). > > That won't scale up to well. Think of the update-menus example -- I > don't want to call that for each and every document. > > > > Sounds good and flexible IMHO. Maybe doc-base can provide a parser > > > class for it as well to avoid that every program needs to reinvent > > > the wheel. > > > > I don't see how a parser (that would be written in, say, Perl) fits > > into my program as a module. Communication over stdin? A parser > > for everyone would be nice but how could it be done cleanly? > > If we're concerned about a parser, I think the best thing would be to > provide an XML data interchange format. XML parsers are cheap and > plentiful. Or is that too much? No, I think XML would be a nice solution. Bye Racke

Previous Message by Thread: click to view message preview

Re: future of dhelp

> > > I provide a /usr/lib/doc-base/hooks directory. Each file in there > > > should be an executable (script or compiled program) that takes a few > > > different first arguments (install, remove, version, possibly > > > 'update'). > > > > > > If called as "/usr/lib/doc-base/hooks/program version" the program > > > returns an integer, what version do I understand. > > > > > > If called as "/usr/lib/doc-base/hooks/program > > > {install,remove,upgrade}" it will accept one or more doc-base file in > > > the format that it understands in stdin (we'll have to figure out a > > > file separator for separate doc-base files passed all at once). > > > > > > How does this simple first-cut sound? Some ideas that I'd like to be shared and weighed out by you: If we decide to ask the program for version compatibility, then we need to at least back our new file versions through debian package version dependencies. For example, dhelp in the current stable branch does not support version querying at all. Or some new package system decides to support only from version 2 upwards. What I want to say is that different file versions (as discussed by you) involve different debian package (version) dependencies already. So why not drop the ".../hooks/program version" idea for the sake of package interdependency, solely? When packages register with doc-base through 'install-docs -i ...', they do so one by one. Given that's correct, how would doc-base be able to notify dhelp about _several_ new docs (through 'program install') at a time? (The 'file seperator' thing again.) Is there something like a commit phase for 'install -i' so that all actions can be fulfilled at once? Please tell me if I'm complicating things :) and your opinions. Buy! -- Daniel mailto:daniel.nouri@xxxxxxxxxxxx ______________________________________________________________________________ Wenn POP fur Sie mehr als nur Musik ist. Senden Sie Ihre SMS direkt aus Outlook oder Netscape! http://freemail.web.de/features/?mc=021177

Next Message by Thread: click to view message preview

Re: future of dhelp

"Daniel K. Gebhart" <dkg@xxxxxxxxxxxx> writes: > > Stefan Hornburg <racke@xxxxxxxxxx> writes: > > > If we're concerned about a parser, I think the best thing would be to > > > provide an XML data interchange format. XML parsers are cheap and > > > plentiful. Or is that too much? > > No, I think XML would be a nice solution. > > Sure. XML would be very comfortable to parse with python.. but it's not > so much "Debian like" then RFC822 conform files. I don't see a point in being "Debian like" just because. Another small thing that's not clear to me: What if dhelp installs after documents? How is that solved ATM? Can I expect a DTD anywhere in the near future or should I go about it? -- Daniel mailto:daniel.nouri@xxxxxxxxxxxx ______________________________________________________________________________ Werden Sie kreativ! Jetzt HTML-Mails nicht nur schreiben - nein - GESTALTEN, bei WEB.DE FreeMail! http://freemail.web.de/features/?mc=021141

Loading Comments...