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