On Mon, Apr 4, 2011 at 4:24 AM, Brian Ledger <[email protected]> wrote:
>> I must say I like your approach very much, however in some cases having 21 >> methods allows the user to write the code in a more declarative fashion for >> example "subscribe sock ..." vs "setsockopt sock subscribe ..." or "has_more >> sock" vs "getsockopt sock rcvmore".] We face some common questions in all language bindings. The two main ones seem to be (a) how to improve existing bindings and (b) what level to aim bindings at. My own views are as follows: * It's generally best to improve into an existing binding, unless the authors are absent and silent, or there is a real need for a fresh approach. Forks confuse people. * It's profitable to map libzmq's API closely (including to keep zero-copy functionality) but it's also profitable to build abstractions on top. For me it'd be interesting to document and try to share & reuse the abstractions we build on top, e.g. wrapping setsockopt/getsockopt, reactors, multipart message processing. Some reasons for making higher-level abstractions: * it lets you hide differences between versions of 0MQ * it lets you fix misfeatures of the API, e.g. blocking in zmq_term, treating 'more' as a socket (rather than message) property * it lets your users write shorter and clearer code -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
