corey at axcelerant.com
corey at axcelerant.com
Thu Jun 28 08:05:52 PDT 2001
And upon Thursday of June 28, the illustrious Jesse Tie Ten Quee spake thusly...
> On Thu, Jun 28, 2001 at 09:04:28PM -0400, atark at thepipeline.net 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
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:
...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 linuxfromscratch.org
and put unsubscribe in the subject header of the message
More information about the alfs-discuss