SUMMARY: alfs direction
jbeckers at linuxfromscratch.org
Sat Nov 26 02:57:57 PST 2005
It's been a long time since I've been here, for which I apologise. Turns
out studying physics doesn't leave you with a lot of spare time. :-)
I've gone trough the entire discussion here. What follows is a write-up
of my ideas about it.
Thomas Pegg wrote:
> Agreed on all points. And is a good start from everything that's been
> discussed lately.
Same feeling here.
> On thing on about using XML for the profiles, I've begun to not like it
> myself which why I've stopped using it for my own purposes short of
> doing updates for the profiles and making sure everything works as it
> should within the profiles.
I know exactely what you're saying. When I find the time to maintain the
BLFS profile (that hardly ever happens, like once a month or so), I can
never do something usefull because the XML is such a big hurdle. I
really feel like preparing a release of the profile is like fighting a
war against it, and it shouldn't be that way.
Hence I propose to ditch xml entirely, except maybe for the
communication protocol (that is: If we use SOAP, we'll obviously need
xml support). It has been proven in jhALFS that we can parse the book to
sh-commands directly, so the use of xml to represent the commands has
pretty much gone.
The only way I think xml would be useful is in a system where the
dtd/schema would have *every* possible command in it (even the obscure
ones like bc or so). It wouldn't be to difficult to auto-generate an xml
profile then. It's just a matter of having the xslt processor extract
tags from the book and put them in a "profile" in the right order.
Someone said ant works this way, but I don't have any experience with
it. Don't know how it works out. But as I said before, I favour ditching
xml support entirely.
I hope to see a new tool shortly, so c'mon let's code! ;-)
More information about the alfs-discuss