On 11/10/2011 05:55 PM, Tanu Kaskinen wrote: > 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. Ok, let's leave the notification out for the time being. How do other people feel about making ports a first class object (registered with the core, and all that)? > 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. Hrm, this sounds a little ugly. If so, we could just as well distro patch the notification mechanism. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic
