Hi Johannes,
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.
The way to discover which virtual machines a farm supports is to do a
disco#info on the farm.
http://xmpp.org/extensions/inbox/lop.html#sect-id2257047
The disco#info tells you which vm_species are supported, what the
vm_time_to_live, how long jobs can last, if the farm requires a
password, etc. etc. The disco#info of the farm tells you (the villein
developer) all you need to know regarding whether your code will
successfully execute on that machine.
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?
The disco#info of a farm tells you which read_files you have access to
and thus, what preloaded libraries/APIs/packages exist and can be
utilized. For those that are not supported, you can upload you own
libraries using submit_job --- but, its important that the libraries
don't violate the security permissions set forth by the farm (e.g.
socket connections, graphic card access, etc.) --- such permissions,
again, are all specified in the disco#info of the farm.
Does this makes sense?
Pages 36 through 50 of this pdf might explain it better --- http://markorodriguez.com/Lectures_files/cnls-linkedprocess2009.pdf
.
Take care,
Marko.
