Patch for nALFS

Paul Campbell 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>.

*nods*

> 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.

--
Paul
"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 mailing list