Luca Foppiano wrote:
On Fri, 2008-06-27 at 16:24 -0400, Adrian Likins wrote:
I think it would be useful. At some point it might make sense to split
overlord into an overlord daemon and an overlord client. Maybe even
just a funcd running with a different module set. It would be a bit of
overhead, but some nice abilities added as well.
uhm, actually I don't understand which advantages we can get to split
overlord in client/server....
If we did XMLRPC to the overlord, we'd need to make the overlord a daemon.
If we just allow standard-in and standard-out over martialed formats
(such as XMLRPC marshalling, or perhaps yaml) we don't need that initially.
The stdin idea was just something that occurred to me as something
possibly in the middle.
yes, but it is a good idea ;-)
I think the marshalling over stdin/stdout approach would be easier than
XMLRPC over Local Socket (as opposed to network socket) for many
languages that might have problems using sockets and low level operating
system bits (i.e. Java). In this case, we could either add this to
Func's client "func" (which might overcomplicate it), or make a seperate
app also using the Func API called "func-transmit" or similar. I think
I prefer this approach as then we could have it work simply without any
added options.
cat /tmp/yaml_file | func-transmit # outputs YAML
Of course we wouldn't call this via "cat", we'd call this in a program
using shell modules analogous to Python's subprocess.
Matt, will this also work for you?
I picked YAML above just because we know it has very common language
bindings for all the good scripting languages (and I believe there are
Java bindings). Using XMLRPC outside of an XMLRPC server works in
Python if you know how (and we do), though I'm not sure it works
everywhere as cleanly.
Anyone want to sign up to do this?
Adrian, your idea?
--Michael
_______________________________________________
Func-list mailing list
Func-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/func-list
