[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