On March 12, 2014 at 3:52:38 AM, Martin Sustrik (sustrik@xxxxxxxxxx) wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/03/14 10:02, Paul Colomiets wrote: > Hi Martin, > > On Wed, Mar 12, 2014 at 8:56 AM, Martin Sustrik > <sustrik@xxxxxxxxxx> wrote: >>> Looks like long-polling a/k/a COMET. Please don't introduce >>> this kind of crap into nanomsg. It's used by browsers, because >>> there is not always a way to use websockets. But that's a >>> different story. >> >> I would say it's just a new transport. We should not care. If >> people want a long-polling HTTP transport, so be it. Shrug. >> > > Ah, let me say so: I would be ok with HTTP transport if somebody > would do it fully functional. But I'm strongly opposed to adding a > transport that only works for few cases. And I believe nobody will > spend so much time to make HTTP transport work well for all nanomsg > protocols :) +1. For a transport to be included into the mainline, it should actually work. I agree wholeheartedly. Anyway, I suspect that once I’m ready to share the work in Go, it will be easier to play with new transports without risk to the nanomsg core, or even to my Go core. I’m designing to make it both easy to plug in to existing transports, and easy to leverage most of the work that is common. Any transport that can implement net.Conn semantics can be trivially added .. the main thing will be that constructors for connect and accept will be different. :-) - Garrett Martin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTIDxsAAoJENTpVjxCNN9Y5DEH/iR/FBTc/zA/G2U0Lpx4D6Wv cgNF95Esz3rxVF93ovYeTcAKHCmJ2bvIFo6T6Y6nm0QuM+ZAoWd26vNOtjuEVczc EzcXntgeUqikyaXDyv6KFHxcgSLrirKscdIcLNXCZ5IcQOE2c0afaIecg6R0T+zh /9LRz0OI05cAzyAXx3TOXor7v5McU+U1q8sndbpykYA/5BaeUEoMC8ZcAp0vlW8T gSz9z1K+jw+jYaZ3fDAFLL36WA1UQPu+wUke+Rp+Kc9NQ3ngjD7BkTD5pyl0Fdk0 /c3vNqeWDxCDtXEF38mB1zuzZ2rAhOrm1WD6CYhPHxUyI7LIz45KdBCTuFQacOw= =LIOh -----END PGP SIGNATURE-----