My advice is to use the endpoint string as is for binds, and prefix with ">" for connects.
It's certainly worth trying and cheap to remove if we don't like it. We do a *lot* of create/bind and create/connect combinations. For error handling, I don't see an issue: it can return NULL if the bind/connect returns an error. -Pieter On Thu, Oct 31, 2013 at 4:10 PM, Uli Köhler <[email protected]> wrote: > Thanks for all your feedback! I really like Pieters idea of bind/connect by >> or < characters. I'll try to put together a pull request for that feature. > > @Peter Kleiweg: > In my application, about 80% of the socket creations bind/connect > immediately. > About 10% need to set the HWM and/or other sockopts (mainly IPV4ONLY = > false) > The remaining 10% need multiple binds (runtime-configured) or connects (e.g. > TCP and IPC). > > I assume most applications will have an even higher percentage of "simple" > binds/connects. > Of course, you could still do "classic" binds, but I think especially with > Pieter's idea, the convenience is worth the one extra API function (call me > lazy). > > > Best regards, > Uli > > > 2013/10/29 shancat <[email protected]> >> >> Presumably it's not very often you create a socket without >> binding/connecting it so these don't really "depend on the application". >> >> On Oct 29, 2013 9:04 PM, "Peter Kleiweg" <[email protected]> wrote: >>> >>> Pieter Hintjens schreef op de 29e dag van de wijnmaand van het jaar 2013: >>> >>> > I think it's a great idea and was playing with it also. It should go >>> > into the low level API IMO so it's available to all languages. >>> > >>> > You could make a single API call, zmq_new_endpoint () which has >>> > different syntax for the endpoint depending on direction. E.g. by >>> > default, it's a bind but if you prefix with ">" it's a connect. >>> > >>> > It could also be nice to consider endpoint resolution in libzmq using >>> > an internal protocol as we do for authentication. I.e. bind/connect to >>> > "$myname" which gets resolved by a plugin into "tcp://hostname:port". >>> >>> I think these kind of things are more for applications. There, >>> you determine what the regular patterns are, and you write >>> tiny utility functions that wrap these in a single call. >>> >>> But what those typical patterns are depends on the application, >>> so I don't think this belongs in the library. At least not in >>> the C library. >>> >>> Language bindings for languages that work usually on a more >>> abstract level could provide higher level functionality. For >>> instance, for my Go binding, there is no setsockoption or >>> getsockoption. There's a separate function for each option >>> (which also works well with the godoc system), and there are >>> even some more higher level functions. >>> >>> But what type of higher level functionality is required also >>> depends on the language. Czmq has things that make no sense in a >>> Go binding, because Go does things in a different way. >>> >>> >>> >>> -- >>> Peter Kleiweg >>> http://pkleiweg.home.xs4all.nl/ >>> _______________________________________________ >>> zeromq-dev mailing list >>> [email protected] >>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> >> >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > -- - Pieter Hintjens CEO of iMatix.com Founder of ZeroMQ community blog: http://hintjens.com _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
