[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-
