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, Steffen _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
