SUMMARY: alfs direction

Jeremy Huntwork jhuntwork at
Fri Nov 25 12:01:33 PST 2005

Gerard Beekmans wrote:
> Seems like that's the best way to go for now. And like you said, if 
> somebody doesn't like it, they can write their own client and server.

I don't think I'd ever straight out recommend writing their own server. 
We should have one alfsd that accepts a specific set of pre-defined 
commands. The format of the client is what could be re-done in various 
languages. To that end, too, we could have the main C client accept 
various forms of UIs, so the input/output that it produces should also 
be pre-defined.

> Client sends a <start-install-commands> tag.
> Server acknowledges that it's ready to receive the commands and anything 
> that is now received by the server is stored in some kind of temp file.
> Client sends </start-install-commands> tag.

Yes, this is what I had in mind (though, shorter tags if possible, in 
case we have to edit anything manually. :) )

> Server now saves the file, makes it executable (simple chmod 755 would 
> do the trick) and sends a ready signal to the client.

Is it necessary to actually write to the file-system? If not is it 
beneficial to do so?

> XML or XML-alike. When I say XML-alike it can look like XML if we want 
> but do we need a DTD and all that?

Would have to research that, but IIUC all the DTD does is define what is 
acceptable and what is not in the XML that we're employing. In other 
words, it would be a way of checking validity on the XML. Of course, if 
we're not ever manually editing the XML, but it's only ever used 
internally then the DTD would only be for reference, i.e., if we want to 
write a different client.

> The server could do without libxml and simply do text comparisons. It'll 
> be a case or if statement that compares like "if received string == 
> "<my-tag"> { jump to routine that does this function }

Right, there's no need for the server to depend on libxml2 or any other 
such library.


More information about the alfs-discuss mailing list