On Wed, 2011-11-09 at 09:51 +0100, David Henningsson wrote: > On 11/08/2011 06:52 PM, Tanu Kaskinen wrote: > > On Tue, 2011-11-08 at 09:09 +0100, David Henningsson wrote: > >> On 11/03/2011 08:22 PM, Tanu Kaskinen wrote: > >> > I'd like ports to have their own subscription class. > >> > >> I also think that could be nice, and I looked into that, but as I > >> understand it, it would require every port to be registered with the > >> core (so it gets an index that is used when things change) and several > >> API additions to make it useful. > > > > I'm not sure what you mean by "several API additions", but at least > > registering port objects to the core would be something that I'd > > actually like to see happen. > > Sure, and I'm not saying doing so would be wrong, but it would require > changes to the core, the protocol, the client API, etc. It is not work I > can sign up for at this time. This is part of the public API. We can't easily change it once we decide something. In my opinion having a separate subscription class for ports is definitely the right choice, so I oppose pretty strongly promising applications that they can catch port status changes with card/sink/source events. One option is that we agree to officially not support port status notifications at this point, and implement the right solution later. I assume you have or will have some client code that relies on this notification mechanism. When we eventually introduce the port subscription class, your application will stop working. I don't know if that would be ok to you or not. -- Tanu
