-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24/03/14 08:58, Dirkjan Ochtman wrote: > On Mon, Mar 24, 2014 at 6:44 AM, Garrett D'Amore > <garrett@xxxxxxxxxx> wrote: >>> Filtering on the publisher side is something that should be >>> done. There are some hard theoretical problems involved though >>> (what to do when the publisher is not able to accept new >>> subscriptions?) Also, you are right that multicast is cheaper >>> broadband-wise and doesn't necessarily require filtering on the >>> publisher side. >> >> I think for now, we should keep the subscriber side filtering. >> We can invent a new protocol when/if the need arises. The nice >> thing about the work you’ve done is that it is easy to extend. >> Admittedly, its easier to extend in Go than in C, but that’s more >> due to Pike and company than anything else. :-) > > You should make sure to warn users if you don't do publisher-side > filtering. The difference in performance characteristics for some > scenarios is so large, that I think it should really be > publisher-side filtered before you call it nanomsg-compatible > PUB/SUB. The thing being that nanomsg itself has no publisher-side filtering yet :) Martin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTL+bsAAoJENTpVjxCNN9YzjQH/0ml1bbs5ZRsd/AvJds8hWFp 80igCzLld48o1qJ6w9toQvRBEXQg2rhcJHf3G/r4t2BGbVgwMxhNXhueNMNaSowL bzlZboz0nkf1Eh3jvH0bAyI287HyjN/nyhz6+KHGDgkrUpupmW7SdypgTTVs+gu3 bf0BivwDzzrI9jILmKTpiKQH0chlZsYnNFvDwhho/tSXoqBQqcmx5nS5WkjF89mt A8u8EVj7XdzIgsWNNRoji9BKskctOdjU7yWe1tiYBS2KSj+vTvewJPXMAZ7jQAAf 0LSIS7fnWU4FsH1JZYhs3CSSBPZ33WKt/nv5Hm+wbtGSC3AKh78aRL8zJxm9uqs= =lXQX -----END PGP SIGNATURE-----