[zeromq-dev] Notes from a hackathon

[Luna Duclos]

I'm not sure if I like having picture as a libzmq level thing.
It really only makes sense for C language bindings in my book. most other
bindings use their own serialization mechanisms.

On Tue, Feb 3, 2015 at 2:06 PM, Pieter Hintjens <ph at imatix.com> wrote:

> On Tue, Feb 3, 2015 at 1:01 PM, Doron Somech <somdoron at gmail.com> wrote:
>
> > Pieter - regarding the blog post, I'm not sure about setting the routing
> id
> > on the socket
>
> Indeed, that isn't atomic with sending and so can't work with
> threadsafe sockets. I've changed the article.
>
> I think we can either get the routing id as a message property, and/or
> add a "reply to message" semantic that does this implicitly. The
> second is easier for simple servers, the first is better for realistic
> servers.
>
> Since it only applies to server sockets, I think we would benefit from
> a zserver_reply () method (or similar).
>
> We might also think of moving the picture send/recv API into libzmq at
> some point since it's the immediate replacement for framing.
>
> > I also have a question regarding the session management (really liked
> it),
> > but how would know it is a socket level message and not a application
> level?
> > Also do you think it should be enabled by default or only if an option is
> > set?
>
> To make session management work we'd have to implement it using ZMTP
> control commands, invisibly to the application. Same as heartbeating
> at that level.
>
> -Pieter
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20150203/de0446c7/attachment.htm>