Hi Marko,
I was following the discussion. I think in your example, this is not the
right location for your "environmentid". Instead the environmentid
should be specified within the <in> and/or <out>. IO Data is a contract
to define and execute "remote" API.
For example:
You have an XMPP IO Data service with the JID
"myvmfarm1.server.example.com". It provides the following functions:
#spawn_vm, #list_current_existing_vms, #execute_code_in_vm, #delete_vm
Of course, each function has its own XML Schema for input/output. For
example #spawn_vm function would have some XML Schema that defines a
"virtual_memory_size parameter" and "time_to_live parameter" as input,
and a "environmentid parameter" as output. The XML Schemata of the
#execute_code_in_vm function would define the "environmentid parameter"
and the <code> element (as you provided in your sample) for input.
I think it is easy to realize your vm farming with IO Data. If you
choose to command and control your farms using IO Data to perform your
remote control calls, and you also want to have this all as a standard,
you could write an XEP that defines: 1.) the IO Data based
functionnames(API) a VM-farm-service must provide (as exemplified). 2.
The XML Schemata these functions must provide for input and output. 3.
General instructions how this "VM farming" is working.
IO Data would have an advantage over the other remote call XEPs which
might be useful in your case, too. It defines async conditions. For
example, your #execute_code_in_vm might block if you sent it a
sleep(10000000); // in milliseconds
The caller might lose connection to the XMPP server while waiting for
the result. The async mode of IO Data solves this problem - optionally.
bye
Johannes
Marko A. Rodriguez schrieb:
Hi Stephen,
So I've read the IOData spec over and over (and over) and am starting
to grok it. Basically, as I see it, what separates it from Ad-Hoc
commands is general-purpose XML communication (the child of <in> and
<out> can be any XML, not just data forms)... (and it seems some other
things about schema discovery, but I don't understand the full
implication of that yet.)
I have a question that hopefully you could answer.
There is the notion of a session-id for a single procedure execution,
but what about an "environment-id." In Linked Process, each submitted
job (set of statements to execute) alters the state of a virtual
machine (and there can be many virtual machines running on the same
physical server). The virtual machine has a unique identifier and when
you issue a job, you need to state to which virtual machine that job
is intended. Thus, in IOData syntax, I believe there needs to be
something like:
<iq type='set' from='[email protected]/123' to='[email protected]/456' id='xxxx'>
<command xmlns='http://jabber.org/protocol/commands'
sessionid='RPC-SESSION-0000002'
environmentid='VM-1234'
node='submit_job'
action='execute'/>
<iodata xmlns='urn:xmpp:tmp:io-data' type='input'>
<in>
<code>
for(int i=0; i<10; i++) {
temp + 1;
}
</code>
</in>
</iodata>
</iq>
In short, the "environmentid" is needed to state to which environment
you are altering the state of (which VM you are altering the state
of). While this could be in the "to=" of the IQ tag, the farm is the
only XMPP client in the architecture (much faster/efficient to create
virtual machines without having to log them into an XMPP server and
flood the network with <presence/> -- and no server components
wanted.). Or it could be in the "<code/>" tag -- e.g. <code
vm_id="VM-1234"/>??. What are you thoughts on this "routing" issue?
Thank you for your time,
Marko.
http://markorodriguez.com
On Sep 29, 2009, at 10:26 AM, Stephen Pendleton wrote:
The IO Data XEP already has definitions and an extensible framework for
everything you are trying to do, and more. I think if you tried to
implement
a non-trivial instance of Linked Process you would find that you
would need
the facilities of IO-DATA. This includes support for asynch errors, job
status, job cancel, synchronous and asynchronous jobs, schemata
discovery.
