Michael DeHaan wrote:
Marco Mornati wrote:
Michael DeHaan wrote:
Marco Mornati wrote:
I know what you say and I also know that ls command wasn't a good
example :)
Anyway, where we are using async call is inside OpenSymbolic, and
we have planned to use always async call because inside code we
don't know if a specific command is a "long run" or not.
As I read inside async documentation (on this ML to be exactly) the
difference using nopoll is when the results are shown. if I want to
"wait" for a result I don't need nopoll attribute (that will be
printed when certmaster receive the anwer), else I need the
"nopoll" but, as I seen there's no way to retreive the output string.
As you know we have code symbolic using groovy (java) so it's a bit
difficult to call func using a python API (but I know it's the
better way).
I think for us, the better way to make a func call is using the
XML-RPC (wip, I know) but I wanted to try to make this test using
async call... Result: FAILED :S
I'll try inside our code without nopoll... but I don't exactly know
what could happen... I'll report the results to you...
If you have any other ideas on async let me know
Thanks a lot Michael
Ah, didn't see the "byte-code" in the subject line. It's all good.
Sorry... it was better a presentation before my questions :P
I'll test this and see if I understand where you are coming from.
Yes, having XMLRPC in is going to be nice.
As an aside, for common operations, like "directory contents", it
would be best to write a func minion module for those, so you could
get back structured data, as opposed to just parsing system
commands. Combined with the json output format, that might not
even be that bad to parse, but yes, we want the XMLRPC version or at
least the func-transmit idea that Adrian was talking about. How is
the XMLRPC stuff going? Is there a git branch somewhere we can look
at and possibly offer some help with?
I think could be an hard job if I need to write a little module to
make a simple operation. Now we are using command module especially
to retrieve a system memory (grep Memory /var/log/dmesg) because when
you are using a XEN virtualization if you try to obtain this
information calling some other (direct) function (like hardware
info), the memory you have as a result is: total - virtual machine
assigned memory. So to have a standard way to obtain memory and then
to calculate the virtual machine percentage assigned we are using
dmesg information.
Luca has made some test on XMLRPC and I know (and see) that you have
talked about the implemetation of this feature. We have some other
things to code and test and then we will release a beta version for
you (the problem is always our free time because we are both working
on other "payed" projects ;))...
We will try to make something working next week...
I think func-transmit /might/ be a better approach for
cross-language connections if we are going to rely on permissions
(i.e. Unix socket and/or ACLs), simply because the XMLRPC bindings
for other languages may be hard to coerce to travel over a unix
socket. For Python, we have examples on how to do that, for other
languages with XMLRPC bindings, I'm not so sure it's that trivial.
Perhaps you would like to implement something like func-transmit
instead?
--Michael
Sorry but I don't really know what you mean with func-transmit... I
think will not a big problem the XMLRPC binding on socket using java,
but, as you saind, could be a problem in other languages...
Marco
The thread you need to read and comment on is 'command line api access
ideas'. I believe they make the XMLRPC route totally unneccessary.
I asked who wanted to implement this and didn't get an answer. It's
about a days worth of work I think, since it's mostly just providing a
wrapper script application around the Ovelord("*") kind of API.
If no one wants to do it I can take a look at it sometime, probably
next week. I'd rather someone else take a stab at it though :)
--Michael
Ok... I can take a look and try working on it because in opensymbolic we
now need a method to call correctly func and this is our critical point
of implementation.
I think I'll ask to you some thing and I'll send to you my project ideas...
Thanks Mich...
Bye
Marco
--
Dott. Ing. Mornati Marco
Byte-Code s.r.l
via Antonio Cechov, 1
San Giuliano Milanese (MI)
E-Mail: mmornati@xxxxxxxxxxxxx
_______________________________________________
Func-list mailing list
Func-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/func-list
