Offer better Send/Receive API

[rbx]

Is your feature request related to a problem? Please describe.
The current Send API takes message pointers by reference. The users should not touch the messages after calling Send on it, because it can be sent out at any moment and will be deleted automatically. However if a timeout or some error condition happen, Send will return an status value and the user can touch the message, change it, or resend it. This is not clear with the current API.

Describe the solution you'd like
Instead we should take messages as unique_ptr that user has to std::move to us, giving up the ownership to the transport. To further support giving back the ownership in case of error or a timeout to the user, we should introduce a custom return value that contains a status flag and optional unique_ptr that will contain the message in case of timeout/error. This return value can override the comparison operators for checking of the status flag, which will make it more compatible with the old interface and ease the transition.

Same convention can be used for Receive, where the returned type will contain the received message.

[dennisklein]

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?

[rbx]

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.

[dennisklein]

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.