[zeromq-dev] Fwd: Exact matching on subscription topics

Dimiter 'malkia' Stanev malkia at gmail.com
Thu Jan 19 05:07:08 CET 2012


 From my experience, callbacks are not always good fit for foreign 
languages (python, perl, php, java, lua, etc., lisp).

On 1/18/2012 4:36 PM, john skaller wrote:
>
> On 19/01/2012, at 3:57 AM, Chuck Remes wrote:
>
>>
>> This would provide some room to grow if the library were to ever get a more complex matching mechanism like regular expressions.
>>
>> #define ZMQ_SUBSCRIBE_REGEX_MATCH<int>
>
> No. The way you do this is with a callback. So it becomes more like:
>
> ZMQ_SUBSCRIBE (user_filter_fun, client_data)
>
> this allows the client to write any kind of matcher they like and
> decouples anything but a trivial matching algorithm from ZMQ.
>
> It's not ZMQ's job to perform complex filtering.
> People write massive applications to do this kind of thing!
> Huge huge complex systems! Er .. like Googles search engine .. :)
>
> See below: .....
>
>
>> Alternative #2
>>
>> We deprecate the use of zmq_setsockopt() for setting subscription filters and create a dedicated mechanism for accomplishing this task.
>>
>> e.g.
>> zmq_setsockfilter(void * socket, int operation, void * operation_value, size_t operation_len);
>
> I think I prefer this. "socket options" sound more like a low level tuning thing,
> subscriptions are a very high level abstract thing.
>
> In fact, I would consider the correct interface to be
>
> * construct a subscription manager object
>
> * configure it with filtering details
>
> * create a socket  of type
>
> 	ZMQ_SUB (manager)
>
> Now, ZMQ delegates the filtering entirely to an independent object.
>
> In C++, that object would be defined by:
>
> 	(a)  abstract class with say a virtual "filter(...)" method
> 	(b) A couple of derived classes in libzmq supporting a couple of simple options
>
> For the C interface, you provide as standard a fixed wrapper function which calls
> filter method on the client data cast to the class. The C user can then either
>
> (a) use that, or any other callback function they want to write
> (b) switch to C++, use the fixed wrapper, and derive new classes
>      objects of which become the client_data pointer
>
> So in fact .. I'd deprecate even the existing "fixed prefix matching"
> and switch to a model where the filtering is delegated entirely outside
> of zmqlib.
>
> --
> john skaller
> skaller at users.sourceforge.net


More information about the zeromq-dev mailing list