Another try

Jesse Tie Ten Quee highos at
Fri Jun 29 14:32:33 PDT 2001


On Thu, Jun 28, 2001 at 11:05:52PM +0800, corey at wrote:
>   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.
And XML Parser, which will do all that Hard Stuff(tm) for you and make
it easy to write any app with XML support, just add glue and your away.
But that isn't the point, because if we don't use XML in the right way,
there's absolutly _no point_ in using it..
>   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, duh, of course i am.

The profile is the _core_ of what ALFS is, if we don't do it right, then
there's no point in doing it, imo.

And trust me, there isn't a hell of alot of "logic" or hard work that
needs to be done when it comes to writting a backend, i've spend the
last week or so, looking at code and testing a few things out, it ain't
that bad nor hard. (and if my C wasn't so freaking bad, i would allready
have a working example ;)

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

Well..wait a minute, k, from reading everything that has been said in
the last while, from the sounds of it, you would prefer to just use a
hole whack load of <command> tags, right?

So..then, just think about this, what would need to be implemented in
the backend then? _nothing_ all it would have todo is parse the XML
document and exec a bunch of commands.'s the point of using XML or having the backend in muliple
languages/implementations or anything? why don't we just stop here and
now and write this in bash, because.. from the sounds of it, that's what
your pushing for, you want total control but you don't want to give the
backend _any_ control over how it gets done.

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

Why? if we don't talk about this now, we will talk about it tomorrow,
next week, next month, etc... :)

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

Gerard posted a nice reply to this, he did a much better job then i ever
would ;)

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

Welcome to the world of design...

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

tsk'tsk ;)

> <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=''>
> </command>

> <system_command command="configure"
>    param1="--enable-static-link"
>    param2="--prefix=&LFS;/usr"
>    param3="--bindir=&LFS;/bin"
>    param4="--with-curses"
> />

You didn't specific a dir there, so like where are you suppose to exec
that configure script? :)

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

Yeah, more like this thou;

<system_command dir="&LFS;&buildDir;/&linux-dir;"
    >yes "" | make config</system_command>

(id actually like to rename <system_command> to something a little more
sane, eg, <exec>, <command>, etc)

But, again.. i strongly believe that, that tag should only been used
when it needs to be used, eg, like a above in the linux kernel

Actually, the breaking down part is where we (afiak anyways :) are
going, eg;


I think the reason this has caused so much trouble is that you came off the
point of saying we should ditch all the tags, for complete control with
using one main tag, eg, <command>.

And like i've mentioned above, this was something i know Simon had a
hard time at first believing (well, he was more playing the devils
advocate ;) in that, if we go that way, all we are really doing is
making a shell script in XML.

Sure, that would give us complete control, just like a shell script
would, but that then we take no advantage of XML or anything else...

Does that make a little more sense?

I love control also, why do you think i use LFS?  But, how much control
do we -really need-?  We are just installing packages here, this isn't
brain surgery or anything, and it's XML so it can always be extended in
the future.

Anyways.. i'm sending this before i revise it yet again, else i'm never
going to send this =)))

Jesse Tie Ten Quee - highos at highos dot com
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