nALFS2 Daemon and Front Split

Kevin P. Fleming kpfleming at
Tue Aug 10 21:20:36 PDT 2004

James Robertson wrote:

> Following this then, here is a list of features for the back-end:
> * Engine for the build
> * Runs on the target machine only (from a boot-cd, or floppy or 
> whatever, just meant to be the piece that does the work on the new LFS box)
> * Contains all the handlers for all the xml dtd syntax/schema functions 
> (make, move, unpack, download, [put your favorite here], etc)
> * Handles the features of xml parsing and validation
> * Runs on a documented unix socket/IP port for remote connection by the 
> client.  Remote in this sense can be the same machine, hence the socket 
> pair provided.  Remote can also be another box with the client on it 
> over a network of some kind.
> * Provides no GUI, it is a daemon after all.
> * Provides a remote client with the ability to control its actions and 
> also handle information/control messages/commands to and from the client 
> and itself.  The daemon will need to have a documented control mechanism 
> for every possible client scenario.  Any client that then take and use 
> only what it needs (a CLI would want different info than a GUI)
> * Handles all logging state information on the host it is building on 
> (in /var/nALFS/...) using the logging dtd or schema
> * must be compilable into binary machine code, should not be implemented 
> as/in a scripting engine or interpreted language

Agreed with all of these.

> This is a list of features for the client:
> * Display and control tool for the build engine
> * Provides a mechanism to communicate with the back-end, control its 
> function, get information back, etc.  Does not have to be a GUI.  A 
> command line tool can do everything.  Think like an FTP client that 
> connects to a server daemon.  The FTP client controls the actions of the 
> daemon and gets feedback on what is going on.  There are both CLI FTP 
> and GUI FTP clients out there.
> * Can "see" the state information on the remote host and manipulate it, 
> for example, report on packages installed and when, etc.
> * Provide for profile editing?
> * Can, connect to more than one daemon at a time and allow switching 
> between them, or viewing all at the same time.
> * Can be written in any language.  I can be compiled into machine code, 
> or run from an interpretive language.

Agreed with all, except for profile editing. I don't know if that 
belongs in an ALFS client at all, since what is required is a DTD- or 
schema-aware XML editor, there's nothing special about editing ALFS 
profiles vs. general XML documents. If someone wants to integrate an 
editor into their client that's cool, but as far as the daemon is 
concerned it will just be asked to drop and reload a new version of a 
profile, it won't be aware of the edits themselves, and it won't have 
any reason to spit the original XML back out to the client after it has 
parsed it.

More information about the alfs-discuss mailing list