Spec: clearer http::Server registration methods

[favreau]

+1

[rdumusc]

This is a complex topic :-) Maybe let's discuss it offline tomorrow, but here are already a few thoughts:

• Using GET/PUT in the names really make this a http-specific API, separating it from the binary/zmq interface. It is an option to go that way, but I think it might be more helpful to tend towards unifying the two APIs instead, to let users transparently expose objects through both protocols.
• handle prefix is not bad but it has a sense of "immediate action". I would prefer to use register (although it has the issue that it is a reserved language keyword) or simply add or maybe expose or serve.
• 12 overloads look scary... how about having just one pubic remove() function?

Since I started thinking about it, a unified API usable for both binary and http server could look something like this: _server.add( camera ); // defaut to zeroeq::ReadWrite _server.add( frame, zeroeq::ReadOnly ); // or zeroeq::OUT _server.add( httpCommand, zeroeq::WriteOnly ); // or zeroeq::IN _server.add( "myapp/getinfo", myGetFunc ); _server.add( "myapp/setoption", mySetFunc ); _server.remove( anything ); And for the "publish" or "send event" actions (N/A for http server): _server.send( camera ); _server.send( event ); _server.send( event, data, size );

[eile]

A few comments, let's discuss tomorrow:

• The http server semantics are different from pub/sub, they are closer to req/rep. For this reason I lean towards a different API between http::Server and Publisher/Subscriber
• handle: maybe, here it means 'handle this guy from now on'. It was the best we came up with.
• one remove overload should suffice.
• I would prefer _server.add( camera, zeroeq::READWRITE );
• Not sure if there is a need to change the pub/sub API

[eile]

• add implies it can be done multiple times for the same object/type, which is not the case. set( camera, zeroeq::READ ); would be the correct API - we could even replace remove with set( camera, zeroeq::NONE );

[rdumusc]

Yes, I jumped a step in the example above in assuming we would at some point introduce a zeroeq::Server which is a Publisher with support for req/rep, something I have had in mind for some time :-)