[Coldstuff] ColdRPC draft

xmath xmath@nubz.org
Tue, 8 Jan 2002 13:19:28 +0100


OK, based on what I've read, I'm still sticking to my current ColdRPC design.

I'll explain later in more detail the reasons why.. but the basics are:

1. it should be simple and efficient
2. it should be nicely symmetrical, asynchronous, and have support 
for message fragmentation
3. it should allow for ColdC methods to be called remotely, and 
therefore carry any value representable in Cold

Using any text-based protocol already basically rules this out: they 
have too much overhead without having any benefits in this situation. 
The only advantages of text-based protocols are:
1. easy to use by humans: irrelevant after the debugging phase, 
ColdRPC is used between programs, not between people. for direct use 
by humans, I'd rather make a convenient little tool, 
"ColdRPC-Console" or so.
2. extendible: ColdRPC only needs to be extended when new value types 
are defined, something that very rarely occurs. Even when it does, 
ColdRPC still has enough room to add it without incompatibility.

No existing protocol (as far as I know) has the features I'm looking 
for, nor does extending some existing protocol have benefits over 
making a new one.

In short, ColdRPC is simple, efficient, specialized at Cold and it's 
good at what it's specialized at.

If people want I can work on MCP some time in the future, I agree it 
would be nice to be able to support MCP-clients, but personally I'd 
prefer ColdRPC over MCP anytime: for communicating with a Cold server 
that is. MCP is nice, but doesn't do what ColdRPC can do (if you're 
logged in as programmer, ColdRPC can directly call any method with 
your privs, even for example if you can't use the eval command 
because of a .read() in progress), because MCP is meant to be 
universally useful, and therefore doesn't harness the features of 
specific systems such as Cold.

And indeed, if Brandon doesn't like method meta-data, then I can 
instead make a $remote object or so, which will allow you to mark an 
object as remotely callable, and specify exactly which methods may be 
called by an unauthenticated RPC session. (or use $dmi_data if that's 
in any way still relevant.. haven't looked at it)

  - xmath