nALFS2 Daemon and Front Split

James Robertson jwrober at linuxfromscratch.org
Tue Aug 10 19:34:47 PDT 2004


All,

I wanted to noodle some more on the split between the two pieces.  Sorry 
Kevin - I may still be confused :-)

Kevin and I posted some notes on the wiki at:

http://wiki.linuxfromscratch.org/index.php?pagename=SplitnALFS

Kevin mentions that we are using the word "daemon" in a backwards sense, 
since we are having the workhorse be the daemon on the target machine 
and the client being a lightweight piece to "watch remotely" what the 
target machine is up to.  That is OK.  I was still kinda confused on 
this until I finished writing the feature list below.

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


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.

This is what I got so far.

James



More information about the alfs-discuss mailing list