The single biggest problem I see people having in the JVM community is their lack of understanding of the concurrency model. I haven't had time to internalize the proposal just yet but if it helps people write better/simpler software, I'm all for it.
-Trev On Tue, Feb 3, 2015 at 4:33 PM, frank <sound...@gmx.net> wrote: > Hi, > > Please excuse for writing this on my phone.... > > I do not see any usecase nor detailed motivation what the problem is that > causes this somewhat fundamental proposal. > > I think this approach is somewhat surprising and against the C4 thing. Not > sure if this is a problem or not, but there is a lesson there somehow. > > Could you please (re-)publish the problem descriptions? Is the problem in > czmq , netmq, go-bindings or really in libzmq? > > Apart from this 'style' related thing, i have a technical question: > > When a router (API4.x)received a curve-encrypted message, i thought that the > identity field was the indented way to identify which of the many possible > clients send the message. > > In fact I was thinking of signing the identity field using the client secret > key to have a robuster way of stopping clients which woul like to steal an > identity. > > So with an 'int' as ID how is it possible to distinguish client1 from client2 > cryptografically? > > Or did I misunderstand how this should have been done in API4.x? And is this > possible with api5.x? > > > > kind regards > Frank > > > > > > -- > unterwegs > > Am 02.02.2015 um 10:23 schrieb Pieter Hintjens <p...@imatix.com>: > >> Hi folks, >> >> We had an interesting pre-FOSDEM hackathon on Thursday and Friday, in >> Brussels. >> >> One of the threads that came out, thanks mainly to Doron Somech >> (NetMQ) was a strategy for simplifying ZeroMQ. This started as a >> discussion of Nanomsg's dropping of multipart messages. >> >> Overall, multipart messages add a lot of complexity and confusion to >> the library and bindings. In case we forget: >> >> - frame vs, message vs. part >> - routing id frames >> - request-reply envelopes >> - router sockets >> - identities >> >> Multipart messages are the main reason we can't make threadsafe sockets. >> >> So, we're going to experiment with shifting ZeroMQ (libzmq, NetMQ, >> CZMQ, and other bindings) in this direction: >> >> - deprecate multipart messages from the API - when we need framing, we >> can use zproto >> - deprecate ROUTER and DEALER and slowly replace with SERVER / CLIENT >> sockets that refuse multipart data >> - deprecate REQ and REP >> - SERVER has get/set routing ID on message >> - routing ID is an integer >> - routing ID cannot be set by peer, so we deprecate ZMQ_IDENTITY >> - start to aim for threadsafe sockets >> - deprecate the ability to build request-reply chains >> >> ... >> >> This is not a roadmap, nor is this a proposal, it's just a realization >> by several of us that multipart messages create complexity, which we >> dislike, and which causes cost and irritation. >> >> Cheers >> Pieter >> _______________________________________________ >> zeromq-dev mailing list >> zeromq-dev@lists.zeromq.org >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
