Hello,
I'm reading over the comments about Linked Process now. I was on
vacation for the last week and a half so I'm getting caught up on this
thread of emails as well as the 300+ other emails I have in my inbox
(doh!).
On Sep 24, 2009, at 4:47 AM, Fabio Forno wrote:
The big advantage of an RPC-like scenario is extensibility. Future
improvements or vendor specific enhancements of the APIs you are
reflecting over XMPP could be easily incorporated without changing a
specification, which is a thing requiring a formal process and time.
And among all different RPCs approaches I'm more keen toward IO-DATA,
since it easily allows tracking the API version you are using.
The thing that we need to stress is that Linked Process is not an RPC-
based model of distributed computing. There is no "API" on the remote
machine. Thus, there is no notion of methods/functions, parameters,
and return types. The best way to think about Linked Process is to see
it as a XMPP-wrapper to a "language console/command line/interactive
interpreter" on a remote machine. Thus, with Linked Process, you are
simply sending over language commands/statements/code. Examples include:
* 1 + 2;
* var temp = 1 + 100;
* for(int i=0; i<1000; i++) { temp + 1; }
* def increment(int value) { return value + 1; }
E.g., in the groovy runtime shell on your local machine, you could so
something like:
groovy> 1 + 2;
==> 3
Remotely, with Linked Process, you send "1+2;" and get back "3". Thats
all there is to it :). With Linked Process, you are not invoking
remote procedures. In fact, you can, at runtime, define your own
procedures. The remote machine serves as a general-purpose computing
sandbox that can be programmed to execute any desired algorithm as
long as the algorithm does not violate certain security restrictions
set forth by the farm [ http://xmpp.org/extensions/inbox/lop.html#sect-id2257047
]. Again, there is no "API" on the remote machine --- just a general-
purpose language specific virtual machine that you spawn to execute
code with.
Thus, the XMPP protocol is very simple as you don't have to deal with
data forms (complex data structures being passed between between
client and server) and different methods/procedures/functions. There
is no procedure discoverability requirements and no API schemas.
NOTE: Josh and I are reviewing Ad-Hoc commands as that may fit our
scenario, but as we see it now, it doesn't make sense to ride Linked
Process atop of IO-Data.
Please comment if you believe what I'm saying is in error or lacking
in reason.
Take care,
Marko.
http://markorodriguez.com
