[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