Offer better Send/Receive API about fairmq HOT 3 OPEN

Was discussing this with Matthias a bit more. Actually, I think we should not expose pointer types to the user at all, but just take and give plain move-only FairMQMessages by value. The same we should imho apply to the FairMQTransportFactory member functions.

@rbx What do you think?

from fairmq.

What I have in mind now, especially after considering possibility of having our own header and some other discussions we had, is to offer a new fair::mq::Message class. Which will be:

• move only.
• contain multiple buffers/parts that user can read/write/add/remove (if i'm not mistaken this is similar/same to what you once proposed with multiple buffers).
• will have methods to access header values.
• ... ?

Internally it can be just built out of FairMQParts (which are also move only and non pointer), where one or more parts are reserved for our headers or anything really, since we will not expose internal parts to user.

Regarding what factory returns i am not certain, it indeed can return those move-only types, but then it has to give up ownership.

from fairmq.

This article has a lot of answers on how to implement our interfaces with value semantics: https://akrzemi1.wordpress.com/2012/02/03/value-semantics/

Regarding what factory returns i am not certain, it indeed can return those move-only types, but then it has to give up ownership.

Indeed, I was not telling all the details. After thinking about it, the sockets should have shared ownership on the transport, device also has shared ownership on transport. When we need to communicate something to the sockets, we also need to track (non-owning) pointers to the sockets in the transport. Once a socket is destructed, it will deregister itself from the transport. I believe this would be the cleanest implementation. But there is no rush, let's take the time and think it through another couple of times.

... is to offer a new fair::mq::Message class ...

This would be a great migration strategy. If I may rephrase Use the overdue namespacing of some of our classes to introduce a new API in parallel and then deprecate the old API at some point.

from fairmq.