jwrober at linuxfromscratch.org
Fri Dec 10 19:19:10 PST 2004
Jeremy Huntwork wrote:
> James Robertson wrote:
>> I have gone through the SRS as best I can on my own. You can see the
>> BZ entries for nALFS2 at
>> and the SRS at
>> I need you all to look through it and make comments. I especially
>> need help with the following sections:
> I looked through those pages extensively, and you've done a great job so
> far, many thanks. I intended to sit down and begin filling out some of
> those items you mentioned as well, but there were a few blocker points,
> it seems; a few things that haven't been completely decided yet and that
> will affect what we list in your SRS.
> 1) The testing we've done on parsing the book as a profile shows that
> it's both possible and practical, therefore I'd like to see this become
> a standard feature. However, I don't think we're quite ready to ask the
> current LFS editors to add our tags to the book, I'd like to have
> something a little more solid first. To that end, I propose that, for
> now, we maintain diffs of the book that will allow us to parse it.
Oh, I think we are quite close. Lets bring it up. I think more
verbiage in the srs is in order. We just need to find a good place to
put it. Probably in the main section 3 somewhere.
> 2) In using the LFS book as a profile, what sorts of standards or means
> will we employ to add to or customize the build? How will we do this?
> By calling up an external editor in which we can insert our own
> commands? Parsing another external file? Suggestions?
Those are all good questions that I do not have answers for. I need
smarter folks than I to handle this one.
> 3) We need to finalize a development language. AFAIK, at this time we
> are heavily leaning on C, but there has been nothing stated officially
> that we will be using that to build our tool. Looking at our wiki docs,
> is there a better choice?
I would think for the daemon that C is the best choice. One of the
great things about implementing a true client/server model is that the
client can be written in any language. We should provide a ncurses
console based one written in C as well, but that does not prevent
someone from writing one in Python or C using the X libraries or
something (heck, can we provide that too?)
> 4) A comm protocol needs to be decided, or at least addressed, so that
> we can work that into the Back-End design from the start.
I agree with Jamie that SOAP is probably our best bet at this time. It
has been around for a few years (4 I believe) and is quite mature and
> 5) To what extent does RelaxNG play a part? Esp now that we hope to be
> parsing the LFS Book straight out, how will RelaxNG fit fully into this
> picture? I'd like to see something more concrete written out concerning
I agree with Matt that RelaxNG is not a requirement. We just need an
XML based schema as opposed to an SGML schema like we have today. If
DocBook is going RelaxNG, then I think we should do that too since we
rely so heavily on DocBook for the main product we product (the LFS Book).
> Are there any other items that appear undecided to you? I'm anxious to
> be moving forward on this, so let's get the above and anything else
> that's outstanding finalized now.
> Jeremy Huntwork
Thanks Jeremy. I don't think so.
More information about the alfs-discuss