I will try to approach this from a general standpoint.
I request people's oppinions on this subject as well.
I know this is boring, and the talk of too damn many hypists (can I claim
to be any different: I don't know...).
first of all, general requirements I guess:
the protocol should be fairly simple (a partial but working implementation
should be possible quickly, and other implementations may not be able to
expect "correct" behavior in all cases).
that it be possible to easily add whatever features are desired to the protocol
without possibly breaking capability, and being capable of easily determining
what is supported by a peer (it should be possible to readily mix-match features
from different extensions in the same message as well).
there should not be schemas or requirement of statically defined information
about what is being connected to or how it should operate.
that more or less any node can export functions and give references to objects
(and not to have, eg, a global ip address, a registered hostname, ...), and
there is little assumption about the reliability/longevity of references.
that the protocol be capable of handling dynamic typing effectively, or at
least not treat it as a "fringe" feature.
the typesystem and message types should be easily extended by possible ad-hoc
no real assumptions should be made about the typesystem/object system/langauge
semantics/... in the base protocol (though, this should be competently addressable
these are only the basics as I imagine them, but could be a starting point.
I imagine more advanced behavior can be delayed. I will state that performance
is not a major concern.
I will argue that many existing systems have various deficits:
would likely require a fairly developed xml parser, as opposed to the "half
assed" parser of many apps, often maybe only supporting tags, attributes,
and bits of text;
does not seem that it would work very well with an only partially complete
does not seem straightforwardly extensible (or at least not in the "keep
basic stuff, pile more ad-hoc crap on top" type mentality, eg, it seems to
view itself too much as the "end all" protocol).
in itself lacks a good extensibility mechanism;
no-one seems to be behing spec'ing and archiving various extensions (eg:
like what is done by the jabber group);
existing people dealing with xml-rpc have virtually o interest in anything
I say (well, not like I say anything woth while);
otherwise I am a strong supporter of xml-rpc.
more conventional rpc's in my mind don't really need to be listed (personally,
I don't consider them really anywhere near sufficient...). I know, this could
be classified as trolling, but I will that this as my oppinion.
it requires incomming connections;
little facility exists for effectively merging/passing messages between multiple
nodes (another protocol would probably be needed for this, likely tied to
the specifics of the server).
with http, little info is retained about the caller (or at least not without
the info being stored in the payload, or special addon features to http);
for the case where things can run on a server and these aren't a problem
it may well be a decent option (except I am not as much a fan of requiring
multiple connections for concurrent calls).
there is some variation in the workings of the email system (eg: smtp/pop
vs. hotmail), possibly some kludging would be needed to seperate user emails,
eg, from rpc calls. I am somewhat unsure about performance, and would think
some additional security measures might be needed.
I am a personally a fan of xmpp. it doesn't seem to have many faults in my
mind (beyond the lesser concern of performance). specs for transport of both
xml-rpc and soap over xmpp exist. even without them: adding support is fairly
straightforward, and the handling of unknown extensions is straightforward
(they are ignored).
there may be other worthwhile transports I dont know about. others?
protocols I believe are more a matter of politics than of technology though,
which is why I believe a strong voice is needed (though, there is allways
a large chance that an inferior technology will win...).
I do not believe there exists a "one true protocol"...
well, this is language specific land.
preferably the interface should be fairly straightforward or transparent.
I believe it should be possible to retain as much of the language's native
features/quirks as possible for supporting nodes (this is where extensibility
goals come in), but in case less is supported things should remain operable
(eg: special types are sent as more general ones, or maybe the message fails
if the other end does not know of some "required" feature...).
for more primitive languages (eg: c). it may be useful to just statically
define some amount of the interface and use a tool to spit out a glob of
code to mask over calling issues (eg: making them look like local c functions).
protocol issues should still remain a minimal concern of the code, and it
should still be capable of dealing with other languages with different behavior
(eg: recieving a call with invalid arguments for the language/function results
in a fault being returned...).
(in fact, I would be quite supprised if say, a haskell, smalltalk, and lisp
node could communicate without making a large number of comprimises wrt interface).
thus, I will assert that external interfaces should be "as minimalist as
languages is probably the main place things get ugly, but I believe the language/application
issues are still important at the protocol layer...
I still believe this is only the basics. more complex issues, eg, finding
stuff of interest, moving "complex" data/types, copying code, spawning/joining
remote threads, transactions, ... I believe are outside the present scope
of this ideal (more so, I believe these kind of things should be built "on
top" of the rpc protocol, as opposed to being part of it). necissarily, using
features of this sort hinder compatibility (and I believe this is the "correct"
behavior as well), but I believe it is very important that they remain usable.