[zeromq-dev] [zmqpp] Proposed interface addition....possibly breaking

[Goswin von Brederlow]

On Wed, Jan 15, 2014 at 08:19:33AM -0500, Lindley French wrote:
> I have an idea for updating the zmqpp::socket interface. Unfortunately, I
> don't think it's compatible with the current interface, so I want to run it
> by the list before going down this route.
> 
> The zmqpp::socket interface already includes send() and receive() overloads
> which take a std::string instead of a zmqpp::message. My idea is to extend
> this to arbitrary lists of types supported by zmqpp::message, using
> variadic templates. This would allow you to do things like:
> 
> // Sender
> socket.send("Hello",5,8.4,"Have a nice day");
> 
> // Receiver
> std::string str1, str2;
> int val;
> double dval;
> socket.receive(str1,val,dval,str2);
> 
> So long as the types match up, everything would "just work". And frankly,
> matching the types up is already a requirement so that's not adding
> anything new.
> 
> I've already figured out how to do this in code. The problem is that the
> existing send(string) and receive(string) overloads take a second parameter
> indicating whether or not to block. This second parameter can't be used
> with the variadic template overload, and if the existing overload is
> retained, it would be ambiguous. My proposal is to use a function template
> parameter, BLOCKING or NONBLOCKING, to communicate this information.
> 
> The send(zmqpp::message, bool dont_block) overload would be retained, and
> in fact the variadic overloads would eventually end up calling this one.
> 
> There is an alternative approach which doesn't break the existing
> interface. I don't think it's quite as "cool", but it ought to work: use a
> builder pattern instead of variadic templates to construct multipart
> messages. I haven't figured out the code yet but the syntax might look
> something like:
> 
> // Sender
> socket.build("Hello")(5,8)(4)("Have a nice day").send();
> 
> // Receiver
> std::string str1, str2;
> int val;
> double dval;
> socket.receive()(str1)(val)(dval)(str2);

Wouldn't that have to be

    socket.receive()(str1)(&val)(&dval)(str2);

 
> Not quite as elegant or intuitive, but now compatible with the existing
> interface.

Wouldn't it make more sense to

1) build a message

Message m1("Hello",5,8.4,"Have a nice day");
Message m2("Hello",5);
m2.push(8.4, "Have a nive day");

2) send message

socket.send(m1);
socket.send(m2, DONTWAIT);

3) Build a reciever (a proxy object collecting the memory for all the
   expected message parts)

Reciever r(str1, &var);
r.push(&dval, str2);

4) Recieve data

socket.recv(r);

MfG
	Goswin