On Wed, Aug 18, 2010 at 12:48 PM, Pieter Hintjens <[email protected]> wrote: > OK, so we can solve this using the principle of least surprise. > > We have a large class of simple pubsub scenarios where the best > metaphor is (arguably) "start broad, narrow it down". > > We have a smaller subset of sophisticated pubsub scenarios where the > best metaphor is "start with nothing, then add/remove subscriptions".
I'm not sure if I agree with that. Pubsub seems to imply “start with nothing, then add/remove subscriptions” to me — I can't think of pubsub use cases where starting broad would be desired (rss/news distribution, email subscriptions, chats, market data all imply explicit subscriptions). > One way to solve this is with two socket types, each offering a > specific metaphor, through naming and default behaviour. But that > adds complexity. But you've already got a socket type that performs unidirectional multicast on the publishing side and aggregation of data from multiple sources on the other — ZMQ_PUSH/ZMQ_PULL. If you add support for filtering, it will behave exactly as you've described — initial “subscription” to everything with potential filtering. That leaves ZMQ_SUB with the current behavior (with maybe publisher-side filtering optimizations and support for additional positive/negative filters). _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
