[RFC] SRS Section 3

Kevin P. Fleming kpfleming at linuxfromscratch.org
Fri Feb 4 09:39:24 PST 2005

Jeremy Huntwork wrote:

> 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?

I haven't ever really understood the resistance to having the official 
profile include digest checking; now that the "official" profile assumes 
bz2 format for every package (even those that are not distributed that 
way by their maintainers) the problem is going to get worse than it was 

Someone else will have to explain why people want to supply a different 
compression format than the profile expects without updating the 
profile; the information about what it wants is clearly available in the 
profile itself, and also in the "wget script" included with the profile. 
Personally, I see no need to turn off digest checking at all, and if I 
did I'd understand that to do so I'd have to remove it from the profile.

> 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?

The nALFS-1.3 branch included quite a bit of code to do this; it's not 
really that difficult to implement the if/then/else logic. It's not even 
very hard to implement the standard conditions (shell tests, variable 
values, etc.)... I had most, if not all, of that done. What's harder is 
the conditions based on package status and versions, since the tool did 
not have an adequate database to provide that information.

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

Yes, we previously discussed using some layer on top of XML for the ui 
and the daemon to talk to each other... SOAP and XML-RPC are the obvious 
candidates, but there are others. SOAP is much simpler and easier to 
program against, so it's likely the best choice (Jamie spent more time 
than I did looking into that issue). The point here is that we might as 
well use an existing, documented protocol for communication between the 
ui and the daemon, and one that is easily usable by alternative 
implementations without versioning, formatting, etc. issues.

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

Yes, I intended for that to be in the new tool as well when I was 
talking about this before :-) The ui would just connect to the daemon 
and ask for its current "state" and then continue on from there.

More information about the alfs-discuss mailing list