Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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