Ok. Is there an issue open for this? I'd be happy to take a run at it if that will help get it in the next release, although I can see from this thread that I'm probably not qualified to get it right the first time.
Drew > On Jan 1, 2014, at 8:18 AM, Pieter Hintjens <[email protected]> wrote: > > On Wed, Jan 1, 2014 at 1:12 PM, Drew Crawford <[email protected]> wrote: > >>> 2. we publish all ZAP replies to a secondary inproc:// socket (PUB-SUB) >> >> This also seems curious. I’m wondering if you’re envisioning a more >> complicated ZAP handler in some faraway module as “typical” than the one I >> plan on writing. Basically my entire interest in ZAP is in using it to >> solve this “who is sending me / are they allowed to send me this message” >> problem. If ZAP isn’t the right way to do that, it’s probably worth me >> learning what ZAP is actually for, as that means my mental model isn’t right. > > Maybe it's curious, yes. I'm thinking the ZAP handler has all the > information we need to correlate client IDs (the first frame on the > ROUTER message) with metadata and can provide this to apps in some > way. > > Either it's via libzmq, or it's via another inproc:// path to apps. > There are a few plausible patterns for that. > > Passing the client ID back out in replies is probably silly, yes. > > -Pieter > _______________________________________________ > 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
