SUMMARY: alfs direction

Jeremy Huntwork jhuntwork at
Fri Nov 25 10:07:48 PST 2005

Hey Guys,

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 mailing list