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.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page