Hi Marko,
Marko A. Rodriguez schrieb:
Hi Johannes,
What you say feels right.
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.
Question --- 1 and 2 are clear, but what do you mean by 3? Can you
please elaborate.
In the XEP you proposed you say: "A virtual machine ... can be of any
"species" (i.e. computer language) ... include JavaScript, Python, Ruby,
Groovy"
In my opinion it is important to know what the virtual machine expects
from me as a user. If this (or a way of discovering the *species* of the
vm) is not specified in the XEP a user cannot know what kind of
language/code the VM expects. Therefore I was missing a definition of
what the virtual machine is. And I think it is not enough. It is also
important to know what kind of API it supports... Do you want the user
to *upload* the code libraries to a VM before he runs some code on it?
Another Question --- Does IO Data/AdHoc commands assume statelessness.
What I mean is that, if the same function/procedure is executed twice
with the same parameters/arguments, is it assumed that the
return/result will be the same? Or are such things not decided at the
IOData/AdHoc spec level?
I would say this is not decided at the IO Data level:
Example,
a service called "coffee-machine.server.example.com" which supports a
function with the name #getCoffeeCanStatus, which returns the amount of
coffee in the can. And the can may have a state, full, empty, 55%.. (The
function #brewNewCoffee would refill the can)
Thank you,
Marko.
http://markorodriguez.com
Thank you
Johannes
