[RFC] SRS Section 3

Jeremy Huntwork jhuntwork at linuxfromscratch.org
Fri Feb 4 08:09:15 PST 2005

Jeremy Huntwork wrote:

> ========================================================================
> 3. Specific Functional Requirements
> 3.1 Functionality
> {This section describes the functional requirements of the system for 
> those requirements that are expressed in the natural language style. For 
> many applications, this may constitute the bulk of the SRS package and 
> thought should be given to the organization of this section. This 
> section is typically organized by feature

To me, that would seem to be the clearest way to do it.

> As part of the validation process, alfs will also support the capability 
> to check all packages referenced in a profile against their md5sums 
> before build time.

I'm a little unclear as to what is the best way to implement this one. 
The way I'm thinking, if we're letting alfsd download the packages it 
needs on the fly, then validating via md5sums is a 'good thing'. We want 
to make sure that we've got what we're after.  But if we have manually 
downloaded all the packages ourselves and stored them somewhere, then I 
think the responsibility falls on the user to make sure they are the 
real thing in full. Perhaps, Kevin, you have some thoughts on this one?

> 3.1.2 Conditional Execution
> One of the major problems with the current nALFS is that there is no way 
> to handle conditional execution (if, then, else). To really make alfs 
> the premier LFS build tool, there has to be a way to handle conditions. 

I've seen this one mentioned a lot, but I haven't heard much of anything 
in the way of how we would implement this. Anyone have an idea already?

> 3.1.3 Package Manager Functions

> 3.1.4 Logging DTD

Again, a few ideas on these two and how they work together, please.

> 3.1.5 Split of Front End and Back End

> For the implementation of a client/server architecture, we need a 
> clearly defined and supportable communication protocol between both 
> sides. The only requirement is that it needs to be one in use today in 
> the rest of the world. We do not want to create our own when so many 
> already exist to choose from.

Kevin, you mentioned XML as a communication protocol. I'd like to hear 
some more details on that please.

> 3.2 Usability

I'm honestly not sure that we need this section.

> 3.2.1 Internationalization
> The LFS community is made up of many people from many nationalalities 
> and native languages. nALFS should support a facility of i18n plugins. 
> The native language of the tool will be English, but should support the 
> ability of any native language given a person to write a translation.

I think that would be great - but it's kind of a hard thing to implement 
when LFS itself isn't fully i18n'd, eh?

> 3.3 Reliability

Erm. Not sure how to fill in this section, or if we need to in order to 
start coding.

> 3.4 Performance

> 3.5 Supportability


> 3.6 Design Constraints


  > 3.7 On-line User Documentation and Help System Requirements
> As with any good application, documentation and help facilities will 
> exist for alfs. Current documents are the ALFS DTD Syntax Document, 
> nALFS Users Guide and nALFS Hackers Guide. These will migrate to the new 
> application as will a new ALFS Logging DTD Syntax Document. These four 
> books/guides should suffice for any help a user may need.

Yes, I'd like to see the code well documented in itself, and have a 
users manual/guide written as we go, too.

> 3.8  - 3.12

Most of the rest of that stuff doesn't seem to me to be blocker, though 
we could fill it out whenever we have the info...

There is one other feature I'd like to see implemented, if we can. I 
think I recall hearing someone else mention something along these lines 
too. I'd like to see session handling - I suppose it's inherent in the 
design - but however we implement the communication protocol between 
alfsd and alfs-ui, once alfsd is started building, it shouldn't be 
dependent upon the connection of the ui to continue. If the connection 
gets closed for some reason, alfsd should continue happily along its 
build, and allow the ui to reconnect to view the progress and/or send 
commands such as pausing the build.

Just a thought.

Jeremy H.

More information about the alfs-discuss mailing list