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

[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
> 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
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
> 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
> rebol ordering ... > > 2) use different refinementname instead of /deliver .... e.g.
> /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
> 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?
> 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
> 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
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