Another try

corey at corey at
Thu Jun 28 08:05:52 PDT 2001

And upon Thursday of June 28, the illustrious Jesse Tie Ten Quee spake thusly...
> Yo,


> On Thu, Jun 28, 2001 at 09:04:28PM -0400, atark at wrote:
> > The XML syntax should be written in such a way that one could wirte a 
> > backend in any language.  

  XML cannot *help* but be written in such a way that one could write
  a backend in any language -- so long as said language has an XML
  Parser available -- that's what XML was intended for in the first
  place. Now, how *easily* it is to actually write a backend which
  utilizes that XML is a whole new story.

> > It's not that different than have an API for a programming library.  
> > It's a pretty basic concept.  An API is pretty abstract it's 
> > like a black box, you know what goes in and what come out, but you do 
> > not care how it gets done.  

  I hope we all know what an API is.

> > The backend is the black box.  Who cares 
> > how it is done as long as it gets done?

  I'll tell you who cares how it gets done - anyone writing the
  code will - most definately - care how it gets done. You're
  coming from the perspective purely as a DTD/Schema designer:
  "We're just going to create some tags that abstract what a
  user may need to do, and let those backend guys write reams
  and reams of program logic to figure it all out - the profile
  writers certainly won't care how they do it."

  Well, of course the profile writers won't care what language
  the backend is written in, or how it is implemented in said
  language. But they'll care when they find that all the backends
  totally suck - when they work at all - and don't allow them to
  do the things they need because the DTD/Schema guys designed
  something way too simple, thus requiring much to much complexity
  in the program logic for the backend(s) to do anything slightly
  usefull at all.

> Bingo my man, i've been waiting all week for someone to get this right.
> We are not writting a scripting language in XML, and neither are we going
> to reimplement bash in XML. 

  I would hope not.

> We are however, putting the information in the profiles that an ALFS
> implementation would need to get the job done, we are not telling it
> *how* to get the job done, that's two very different things.

  OK - there's my own hang-up I've been having all along, and which
  unfortunately seems to have caused so much chaos and confusionl
  Sorry guys - I really don't mean to be stiring the shit here - so
  just kick me out if I'm simply being unreasonable and counter
  productive to your project.

  But I personaly just think that we *should* be telling it ( the
  backend ) *how* to get the job done. That's what a custom anything
  is all about - *you* dictate what and how you want *your* item
  to end up like.

  I'm comming from an angle where the xml profile is an open
  specification for directing specific orders to an automated
  process ( the "backend" ), so that it ( said backend ) will 
  obey completely my every command as to produce a linux environment 
  tailored *completely* and in *every way* to my exact specifications.

  In my vission, the xml spec tells me how to talk to the back end 
  and *give explicit directives* - verses, in the seeming direction
  of ALFS, the xml telling me how to say *what I'd like to do*, so 
  that the backend makes the decision on how to go about doing it.

  Subtle and similar - but ultimately very different approaches.

> Anyways.. think about that for a second before even considering
> responding.

  Considered; and I understand where you ( and it seems most/all the
  others - except maybe Gerard, Gerard? - are comming from ). I guess 
  I just have a different idea not only of what constitutes a usefull 
  and customized linux environment, but also how to approach the design 
  and implementation as well.

  Like I mentioned in an earlier post, before Gerard gave some feed
  back to my posts - it may just well be I have different goals/vision 
  than the ALFS project.

> There will always be a <command> (or something similar, right now it's
> <system_command> in the perl implementations) but it should be something
> only used in a very specific situation, imo.

  Sheesh - that's one of the things I've been lobbying for all along,
  and have been getting so much flak for - my bad for not studying the
  existing source first.  But here I am with my:

<command name='configure' src='./'>
  <opt name='--enable-static-link' value=''>
  <opt name='--prefix' value='&LFS;/usr' type='long'>
  <opt name='--bindir' value='&LFS;/bin' type='long'>
  <opt name='--with-curses' value=''>

  unwittingly vs the existing:

<system_command command="configure"

  ...and seeming to get nothing but heart-ache and pain over
  attempting to explain the usefullness of such a construct.
  Granted, I take the certainly debateable method of breaking 
  the arguments down further into key/value tokens - but the 
  exact same concept applies to both elements... What's been
  the big hang-up/disagreement here?



Unsubscribe: send email to alfs-discuss-request at
and put unsubscribe in the subject header of the message

More information about the alfs-discuss mailing list