Patch for nALFS
paul at pauls.bsrg.dnsq.org
Tue Dec 18 09:42:43 PST 2001
Neven Has <haski at sezampro.yu> wrote:
> Locations with type="remote" could be handled differently. Files could be
> stored in some default (and configurable) directory and connection problems
> could be also handled nicely.
Agreed. A top level "meta type" element, or a processing instruction to hold
that kind of parser config data (the download storeage location etc.)?
> We could implement it nevertheless, and it could be only used in rare cases,
> like a fall through or something. But I agree it's not for the standard use,
> for the reasons you mention.
><snip/> > I don't thing that analyzing <archive>
> elements would be very clean solution, it might be better then to just
> specify that <download-url> or something, somewhere below the <package>.
> I also like putting all that "meta" information in the element of it's own.
> I always get a funny feeling after adding even <version> and <name> on
> the same depth level as <build> and friends. It doesn't seem natural to
> me. This is something that Felipe is also suggesting - separating all that
> info from the building instructions (maybe not by using <meta>, we might
> need something more descriptive) could be nice.
I think stealing/borrowing feshmeat's ideas of package discription might give
us some ideas.... Just a thought. I haven't actually looked at this yet.
Surely they must have done some thinking on this kind of info already, and this
is the Open Source way is it not?
> But this would be a big syntax change again, because it's incompatible
> with current profiles. And adding is_new_new_syntax() (god forbid ;) or
> is_syntax_version(3) would make me (and probably Mark) very unhappy. ;)
> I'll start writing ideas like this, so maybe in the future when we have a
> pile of them, we could switch to syntax 3.0, quickly and less painfully?
> By that time, we should also have a good "converter" between different
> syntaxes (you seem to make a good progress with XSLT for example), making
> the change easier in that way too.
Yes. Hmmmm! mmm? Could we not begin to think in a more eXtensible way? I
can't speak from a C programmers perspective, nor any other much language with
much experience, but what about plugin handlers? Do nALFS and ALFS fall over
when they do not recognise an element? Should / could they not just display it
as --> [Unknown element] <meta>. I suppose this would lead to a minor mod at
least, in that the parser would need to search the package element to find the
<name> and <version> elements, as it could be contained in a <meta> or similar
element? aka package/descendant::name (Xpath) *I* think in my limited
knowledge of XML, that this kind of element selection is for the better
as it is flexible.
So I think that a version 3 syntax, might by likely, but, can we pause, and
consider 4, 5, 6, 7 ...... Making them simple extension rather than re-writes?
As for the profile users, I can provide a style sheet to do the job of
transformation (this one would be much easier), as a CGI on my server,
(just backticking till I learn the JAXP and Java serlet foo.) Given a database
of download URLs and package info, (possibly like freshmeat's) I could even
generate the required info for at least aome of the packages. The LFS base
profiles could import the info from the book XML. _ramble_ _ramble_
I would love to roll up my sleaves and get into help in the programming, only I
am putting my aims to learning 21st century programming, due to Uni, and I have
failed to learn enough, C++ or find suitable C++ XML APIs on Linux to learn
enough to help out. I take it that you would consider a Java parser a foriegn
body? I may speak more on this as an acedemic project for myself though.
I hope you all have a lovely, lovely and very Merry Crimbo. And get suitibly
under the influence at New Years.
"Did you sleep well?" "No, I made a couple of mistakes."
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe alfs-discuss' in the subject header of the message
More information about the alfs-discuss