[REBOL] Re: The REBOL messaging engine
From: andreas::bolka::gmx::net at: 11-Aug-2003 21:18
Monday, August 11, 2003, 8:25:43 PM, Maarten wrote:
> I have been working on a messaging engine lately.
Sounds good :) What's the difference to Rugby? AFAICS the underlying
metaphor is rather not messaging but still RPC.
> - Should I add (optionally) message encryption or leave that to
> implementors of messages, as their needs may vary? Pro: Ecnryption
> Con: only works with the SDK, Command, ...
Certainly a nice feature, but I'd rather not add it now. Leave it to
the implementors for a beginning, and if there is a real demand, add
it later.
> - Should I work a bit on the message format so we can port it to
> other languages as well (.NET, Python, etc.) or keep it REBOL-only
> and enhance it, for example integrating a new Rugby on top of this?
+1 for keeping it REBOL-only.
I'd love to see high-performance (!) inter-REBOL messaging, so I'd
like to have a message format purely optimized for REBOL and optimized
for speed :)
On the other hand, if you can keep a good REBOL performance and _also_
rework the format to be more friendly for other languages,
> - Is this API with server based handler functions a good concept or
> is it too hard for most programmers?
I like it. And as the handler-functions concept closely maps to
messaging per se, I'd stay with it.
> - Should I add meta-data so you can query an engine to see what
> messages it udnerstands. If so, what should the meta-data look like?
I'd rather implement that as custom protocol (message types). Any
reasons for adding it as first-class?
> - Should I add authentication, so you can demand that a message must
> be properly authenticated? If so, I'll probably keep it pluggable,
> meaning that you can add your own authentication methods as well.
A nice feature too, but as with the encryption feature: keep the
underlying protocol extensible and add it later.
> - Should I transparently propagate errors back from server to client
> or just return none when an error occurs? It may be annoying to do a
> try with each send-message, OTOH seeing what goes wrong is worth
> something as well.
I'm undecided here :) Just based on instinct I tend towards not
propagating errors ;)
> - Any other suggestions?
As mentioned earlier, I'd love to see this being high-performance
stuff ;)
--
Best regards,
Andreas
