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...).

Protocol

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 extensions.

no real assumptions should be made about the typesystem/object system/langauge semantics/... in the base protocol (though, this should be competently addressable by extensions).


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:

soap (rpc):
seems complicated;
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 implementation;
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).

xml-rpc (rpc):
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.

others?


http (transport):
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).

email (transport):
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.

xmpp (transport):
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"...


Language

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 is reasonable".

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.