Re: Listen / Notify rewrite

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

> This is BS. The problem is not that someone might do something stupid
> with this feature. The problem is that we're making these other use
> cases into requirements which will influence the design. This is a
> classic "feature creep" situation and the result is normally products
> which solve none of the use cases especially well.

Feature creep? The payload has been on the roadmap for a long time. I don't
recall anyone objecting when Andrew was working on the next version of
Listen/Notify around what is probably a couple of years ago now.

> Remember this queue has to live in shared memory which is a fixed size
> resource. If you're designing a queue mechanism then you would
> naturally use something like a queue or priority queue.

Right, but we're not discussing a queue, we're discussing the listen/notify
system. If people want to mis-use it as a queue when they should be using
something else, so be it. Talk of efficiency also seems silly here - using
shared memory is already way more efficient than our current listen/notify
system.

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
PGP Key: 0x14964AC8 200911131234
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkr9mL0ACgkQvJuQZxSWSshkvACg6OQ/SRjkvmozzUogTX3weuio
4ZoAnRVfvcrdMmo+iKtkyXmhAlZqViqF
=6fzv
-----END PGP SIGNATURE-----