AltME: R3 Protocols

Messages

Gregg
I don't either. Probably have an old copy somewhere here. Lad's stuff has been offline for a while I think.
Gregg
I think I liked the idea of a way to build protocols like PARSE lets us build DSLs, but never got it to stick for me.
Pekr
I would not try to overcome port mechanism, whatever it takes. If there are bugs, those should be fixed. Well, it might be an extension (which is C). We will see, how Red IO turns out, once out ...

Robert
I don't like to port model that much. Might be because I never digged deep enough into it. But trying to generalize IO with a common API or model was tried in several other enviironments and all I know failed.
IMO putting network stuff to a higher level makes sense. Much higher level so that I can think of it in sending things back and forther and that's it.
Gregg
Have you looked at 0MQ? It's basically send/receive, with socket types that have semantics (req/rep, pub/sub, push/pull).
Kaj
0MQ looks like that on the surface and in the marketing, but when you start making real systems, you have to do a fair bit more
The problem with those network abstractions is that there quickly are reasons you have to poke under the hood

Gregg
Have you found something better? It's all about tradeoffs, right?
Maarten
Now I'm tickled
Gregg
Kaj, maybe I should ask, instead, what poking under the hood you've had to do. I'm not stressing 0MQ in my work (very low message rates, largely for IPC), but some other work I did with it a few years ago hit it much harder and was still very easy to do.
Kaj
Most simple examples, and what most people start with, is request/reply, but this quickly becomes useless in real-world situations
To be more flexible and scale it, you have to switch to dealer/router, which means managing and interpreting the multiple parts of request/reply messages, including the under-the-hood identity part
Now you're juggling sub-messages and babysitting their consistency, and soon you have to manage the internal sub-messages by creating, copying and destroying them, and comparing their content
First you think, ZeroMQ is about queueing, so I don't have to make my own message queues anymore, but again that only works in the simplest examples
When you need more flexibility and performance, you're back to maintaining your own message queues, and the 0MQ queues become a hindrance, because you can't access them once a message is in there
Kaj
I'm probably spoiled because I never worked with earlier, complex messaging systems, but this is my experience
It would also be different if you're working with low-level languages, but in REBOL/Red a message queue is easy to do, so why give up control over it?

Pekr
Kaj - having your experience with ZeroMQ - what do you think about the Rebol/Services architecture? Is it any better in organising more higher (app) level stuff, than starting with low level ZeroMQ stuff?
Robert
I see BEEP at a much higher level than 0MQ. It's for application developers, you care about the application protocol not the technology below. Here is an even higher-level lib build on top of BEEP: https://www.tml-software.com/
Kaj
Petr, I just happened to review REBOL/Services again with the hindsight of 0MQ experience

Last message posted 486 weeks ago.