SUMMARY: alfs direction
jhuntwork at linuxfromscratch.org
Fri Nov 25 10:07:48 PST 2005
So, from the various comments here's what I see is the direction that we
by general concensus would take with alfs.
1) The server portion of the client (alfsd?) is written in C and listens
on a specific port that we can designate. Encryption or authentication
is a more advanced issue that hopefully we can address later.
2) The client can be written in anything (we want to allow modularity
and the ability to develop clients for any setup), but our POC code and
the main client written by the ALFS team will be written in C.
3) Gerard has already demonstrated the simplicity of establishing a
connection. At this point I feel it should be decided exactly *what*
will be communicated, and in what format. I'm also getting strongly the
impression that XML is not well liked (at least not for LFS profiles),
so we can look at other formats, perhaps shell snippets to send. Once we
have determined *what* will be sent, we can then finish designing how
exactly the server will listen and handle the *what* that's been sent.
As to the *what*, there needs to be a separation of control information
(dealing with commands to control the daemon and current state of the
build) from the data (the actual LFS commands to be run). This could be
in the form of a simple starting and ending tag for the LFS data - all
other information will be commands sent to the daemon, ie, request for
status, instruct to start or stop a build, etc.
All of this could be done in plain text, or in a very simple XML format
that describes commands for the daemon, but the actual LFS execution
commands are always in shell script or plain text.
What does everyone think? Is this a start, some direction to pursue?
More information about the alfs-discuss