kendrick at linux2themax.com
Thu Aug 5 19:33:48 PDT 2004
Kevin P. Fleming wrote:
> Kevin P. Fleming wrote:
>> Ahhh... parsing. I don't much care whether it's SAX or DOM, because I
>> don't see any reason for profiles to continue to be monstrous
>> combined entities. Rather, I'd like to see each package be in its own
>> profile, and nALFS can be told to load a whole bunch of them and them
>> sort them into a usable order (based on dependencies, stage names,
>> etc). This will require nALFS to be able to feed entity values into
>> the parser (which can be done with libxml2), and this is good because
>> there has been a need to be able to provide environment variable
>> values as entities within profiles for some time.
> I missed a really important point here: I see great value in being
> able to provide a "profile repository", something that could be a
> public server (the LFS team could have one, as could anyone else),
> where you could connect using the nALFS front end of your choice and
> pick profile bits that you wanted. This could be a big project by
> itself, given that it would need to support some sort of "packages" of
> profile bits that go together, versioning, and other stuff, but it
> would be really, really cool.
I REALLY like this idea allot and it would allow something like the
hints section to be included for unusual configurations.
Can we make a more or less formal list of what nalfs2 should be? ie
kevins idea of the nalfs and nalfsd. This is the first time I have seen
that listed. Lets get ideas on what is needed to make 2 work. if
nothing else a white board type of thing for ideas? That would allow
discussion on protocols and such if we know what every one is thinking of.
More information about the alfs-discuss