[zeromq-dev] Notes from a hackathon

[Thomas Rodgers]

>
> What we really want IMO is per-peer metadata, and an API to get/set
> this. Using messages is a hack.


Currently working on that :)

Having two layers that both
> carry per-message data is... wrong IMO.


Protocols supporting 'out of band' data aren't exactly uncommon.

However the key thing is, what's the problem. Then we can discuss
> solutions to that.


I don't have an immediate use-case justifying it. I noted it, mostly
because it has come up a few times since I started paying attention.

On Mon, Feb 2, 2015 at 7:55 AM, Pieter Hintjens <ph at imatix.com> wrote:

> > It seems to me that in order to remove multi-part messages and introduce
> new
> > socket types (e.g. SERVER/CLIENT) that would
> > necessitate a revision of the wire protocol. If we are going to do that,
> it
> > might be worth considering per-message
> > metadata -
>
> We'd have to be very clear about the problem that per-message metadata
> is aiming for. There is an elegance to delivering blobs and nothing
> more. Metadata can be added on top using zproto.
>
> What we really want IMO is per-peer metadata, and an API to get/set
> this. Using messages is a hack. If we are sending/receiving data on a
> per-message basis, that is the message. Having two layers that both
> carry per-message data is... wrong IMO.
>
> However the key thing is, what's the problem. Then we can discuss
> solutions to that.
>
> -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/20150202/730a9e7f/attachment.htm>