1. 18 Jun, 2014 1 commit
    • Pieter Hintjens's avatar
      Problem: need way to probe library capabilities · f11d673b
      Pieter Hintjens authored
      As libzmq is compiled with optional transports and security mechanisms,
      there is no clean way for applications to determine what capabilities
      are actually available in a given libzmq instance.
      
      Solution: provide an API specifically for capability reporting. The
      zmq_has () method is meant to be open ended. It accepts a string so
      that we can add arbitrary capabilities without breaking existing
      applications.
      
      zmq.h also defines ZMQ_HAS_CAPABILITIES when this method is provided.
      f11d673b
  2. 17 Jun, 2014 4 commits
    • Pieter Hintjens's avatar
      Problem: when libgssapi isn't available, GSSAPI options 'seem' to work · 27547bc9
      Pieter Hintjens authored
      Solution: use same approach as for libsodium/CURVE, i.e. return EINVAL
      if the library isn't present when libzmq builds, and the application
      still tries to use these options in zmq_getsockopt/setsockopt.
      27547bc9
    • Pieter Hintjens's avatar
      1beb54ce
    • Pieter Hintjens's avatar
      d0667461
    • Pieter Hintjens's avatar
      Problem: API violations are treated as recoverable errors · b4ed3f55
      Pieter Hintjens authored
      The example is applications passing invalid arguments to a socket option
      and then failing to check the return code. The results can be very hard
      to diagnose. Here are some threads that show the pain this causes:
      
      * https://github.com/zeromq/zyre/issues/179
      * http://lists.zeromq.org/pipermail/zeromq-dev/2014-June/026388.html
      
      One common argument is that a library should never assert, and should
      pass errors back to the calling application. The counter argument is
      that when an application is broken enough to pass garbage to libzmq,
      it cannot be trusted to handle the resulting errors properly. Empirical
      evidence from CZMQ, where we systematically assert on bad arguments, is
      that this militant approach makes applications more, not less, robust.
      
      I don't see any valid use cases for returning errors on bad arguments,
      with one exception: zmq_setsockopt can be used to probe whether libzmq
      was e.g. built with CURVE security. I'd argue that it's nasty to use a
      side effect like this. If apps need to probe how libzmq was built, this
      should be done explicitly, and for ALL build options, not just CURVE.
      
      There are/were no libzmq test cases that check the return code for an
      invalid option.
      
      For now I've enabled militant assertions using --with-militant at
      configure time. However I'd like to make this the default setting.
      b4ed3f55
  3. 16 Jun, 2014 1 commit
  4. 15 Jun, 2014 2 commits
  5. 11 Jun, 2014 2 commits
  6. 10 Jun, 2014 4 commits
  7. 07 Jun, 2014 2 commits
  8. 06 Jun, 2014 2 commits
  9. 05 Jun, 2014 22 commits