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

[REBOL] Re: The REBOL messaging engine

From: petr:krenzelok:trz:cz at: 11-Aug-2003 23:41

Andreas Bolka wrote:
>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. >
good question. Rugby was good. It was not fully async, I didn't liked its way-too-long-func-names-without-refinements, but I had fund using it.
>>- 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. >
what about rugby way once again? But please, this time - no more additional function names, use refinements, please "send-message/secure" :-)
>>- 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. >
+1 for Rebol only too. I don't want to sound selfish, but we desperately need rebol engines first, then we can go for further integration ...
>>- 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. >
no problem with handlers ... maybe I would: 1) exchange parameter ordering in following - Send-message echo tcp://localhost:8000 [{Echo this}] to send-message url echo [{Echo this}] .... to be compatible with native rebol ordering ... 2) use different refinementname instead of /deliver .... e.g. /callback, /on-return etc. ... both 1) and 2) are just implementation details though ...
>>- 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? >
well, we should really consider this one. With Rugby, you were able to query server, install remote functions locally etc. Maybe it could really be just a message type, but I would like to have such functionality available somewhere. The point is, that if we will let it upon message-type designers, we will end up with mixture of different aproaches ... it is the same as someone could say - why to build messaging engine at all, if rebol is about messaging in its roots? Well, it is, but we need some more unified way used by rebol developers to take our apps further ...
>As mentioned earlier, I'd love to see this being high-performance >stuff ;) >
Yes, I think I start to understand - new Maarten's thingy, whatever it is gonna be called, is just high-performance async networking message passing mechanism ... Maarten - will it use kind of green threads you introduced in Rugby or how will it divide its time between message-types? What if my message type handler does some more intensive stuff? Hmm, right now I am not even sure what exact usage will that stuff provide us with. I can understand you would like to add Rugby upon it ... but will it be general enough for any kind of protocol, so e.g. someone could create IRC protocol and plug-it into your messaging scheme? -pekr-