[zeromq-dev] More on ZDCF

Steffen Mueller zeromq at steffen-mueller.net
Sun Mar 25 14:39:46 CEST 2012

Hi Paul,

On 03/23/2012 11:58 PM, Paul Colomiets wrote:
> Sure. Checking that both sockets match accomplishes task, isn't it?
> And the thing I really do mix is name of the device, comparing to socket
> types. So I still propose to make all built-in types be implicit (and of course
> all the application specific devices must be explicitly specified).

the role of device types has been a bit of a puzzle for me, too. 
Assorted thoughts:

1) Device name and device type are different concepts. I don't think 
conflating the two helps.

2) Device name needs to be unique in an application.

3) Device type doesn't have to be unique. Eg. there can be many "event 
brokers" that are identical in implementation, but that bind/connect to 
different endpoints.

4) The key point above is "identical in implementation". It suggests 
sharing code via some sort of (application-global) mapping between 
device types and implementations, a subset of which may be built-in.

5) If you one uses a device type that has an already defined 
implementation (such as the built-ins), then most of the information in 
the ZDCF section for this device is useless repetition since the number 
and types of sockets are already defined by the device type. All that 
would be required are the socket endpoints and the socket options (so 
far). But the ZDCF structure doesn't elegantly allow for this use case 
and a better way so far eludes me.

6) For fully custom devices, the device type is meaningless. Thus, I'd 
like to revisit 3) above: Device types shouldn't generally be entirely 
unique since otherwise they're duplicating the device name.

 From this, the only immediate conclusion I can draw is that device 
types need to be optional. As far as I am concerned, anything else 
probably requires playing with global device-implementation registries 
in some ZDCF implementation (for me, that is ZMQ::Declare).

Best regards,

More information about the zeromq-dev mailing list