[zeromq-dev] EncryptedSocket added to pyzmq in branch

Burak Arslan burak.arslan at arskom.com.tr
Tue Nov 2 19:34:30 CET 2010

 On 11/02/10 19:22, Pieter Hintjens wrote:
> On Tue, Nov 2, 2010 at 4:51 PM, Burak Arslan <burak.arslan at arskom.com.tr> wrote:
>> but, i insist that this should be removed from the official pyzmq package.
> :-)
> This goes into the "I'd love feature X!" bucket.  The response is,
> "Great idea, I'm looking forwards to seeing how you do this".

um, 'git rm core/crypto' ?

> As Martin says, the positive side of investing hugely into an open
> source project, as Brian has done with pyzmq, is that you can do
> absolutely whatever you like with it.  It's pointless and somewhat...
> tactless... to demand anything from people who give you stuff for
> free.  Suggesting it's impossible sometimes works, asking nicely
> sometimes works, offering money sometimes works, but strong demands
> are pretty sure to be ignored.

this is not a strong demand -- i'm sorry if that sounds so. i just
wanted to say i was not persuaded, more than once, for reasons i
mentioned earlier.

i also falsely assumed you exercised a more close control over the
bindings, but that's not really related.

everybody is certainly free to ignore my words. but being first to
implement something doesn't make you right about every aspect of that
something. i like to think that my judgement is based on facts, thus
points to the right thing. that's why i find it worthy to share it
publicly in the first place.

so if i'm wrong, you'll persuade me. if you can't, maybe i'm too
stubborn to publicly acknowledge i was wrong. or maybe i'm indeed right,
and that's you who can't swallow your pride??

or maybe you don't even care, which would be bad, because the very
reason open source works is because maintainers (mostly) care about
constructive criticism, and not because every disagreement causes a fork.

> How this works with open source: if you don't like the maintainers'
> decisions and can't live with them, you fork the project, try to
> convince people that your fork is better (and that means investing
> significantly and over a long period of time, not simply offering a
> cloned git with some stuff removed), and by weight of popular demand,
> getting your fork either accepted as dominant, or merged happily back
> into the 'main' version.

there's nothing novel about what you say -- those are pretty obvious.
but i don't see why you're talking about forking. the zmq.crypto module
is totally unobtrusive. i don't see how forking pyzmq would improve

i just don't think it should be there because that's not the right way
of using cryptographic tools.

e.g. std::list doesn't offer operator[]. is it difficult to implement
it? no. (auto iter=this->begin(); while (idx--) ++iter; return *iter;)
but if you need operator[], maybe you should not be using std::list in
the first place?

(translation: c++ standard library does not allow random access to a
linked list, not because it's difficult to do (c++0x implementation
above), but because you shouldn't use a linked list in the first place
if you need random access.)

> Far better, however, is to step back from demands and principles, and
> look at what the authors are trying to achieve (which in this case is
> encryption of traffic) and put your energy into helping them solve it
> in a better way.

if you think i'm not doing that, i'll be disappointed. did you even read
that message?


More information about the zeromq-dev mailing list