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
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
