[REBOL] Re: The REBOL messaging engine
From: maarten:vrijheid at: 12-Aug-2003 7:27
> -----Original Message-----
> From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]] On Behalf
Of
> Petr Krenzelok
> Sent: maandag 11 augustus 2003 23:41
> To: [rebol-list--rebol--com]
> Subject: [REBOL] Re: The REBOL messaging engine
>
> Andreas Bolka wrote:
>
> >Sounds good :) What's the difference to Rugby? AFAICS the underlying
> >metaphor is rather not messaging but still RPC.
> >
That's true, albeit a little less programmer friendly than Rugby. More
powerful though.
> >
> 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.
Yes, but as it turned out the /deferred stuff isn't working (anymore).
So I'm doing async now.
> >+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 ...
OK, but keeping it simple implies that I have time for other
implementations as well ;-)
> >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 ...
>
Yes, they can be easily changed. I'll have a look.
> >>- 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 ...
>
I could add a default message handler, 'meta-data ?
> >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?
>
I don't know how well async I/O works in that case, but I expect there
are no problems in most cases. We'll have to learn as we go along.
> 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?
I don't think so. My idea is to have a block based message format
(that's what I'm using right now) so you'd be limited to that. But
porting it to C# and python is trivial. Interpretation of the message
may e a bit harder there, but that would be the programmer's reason to
switch to Rebol....
--Maarten
