SRS

James Robertson jwrober at linuxfromscratch.org
Fri Dec 10 19:19:10 PST 2004


Jeremy Huntwork wrote:
> James Robertson wrote:
> 
>> All,
>>
>> I have gone through the SRS as best I can on my own.  You can see the 
>> BZ entries for nALFS2 at 
>> http://wiki.linuxfromscratch.org/index.php?pagename=nALFS2Develpment 
>> and the SRS at 
>> http://wiki.linuxfromscratch.org/index.php?pagename=RequirementsDef.  
>> I need you all to look through it and make comments.  I especially 
>> need help with the following sections: 
> 
> James,
> 
> 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.

Thanks

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

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

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.

James



More information about the alfs-discuss mailing list