nALFS2 Daemon and Front Split
jwrober at linuxfromscratch.org
Tue Aug 10 19:34:47 PDT 2004
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:
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.
More information about the alfs-discuss