On 11/11/2011 03:08 PM, David Henningsson wrote:
> On 11/11/2011 12:17 AM, David Henningsson wrote:
>> Do you think we can merge these different views and come up with an
>> agreed client API within a couple of days?
>
> Ok, so I can happily say that we had a great IRC conversation on the
> topic today. The outcome was:
>
> * Not to register port objects with the core (for the time being)
>
> * Not to add "inactive" sinks/sources to the client API (for the time
> being)
>
> * When port availability changes, fire a subscription event for the card.
>
> * I'm not sure we got consensus on if/when the sink/source should also
> get a subscription event, but that can be discussed later.
>
> * To change the existing proposal's "is_input" and "is_output" to a
> bitfield. Thus the new client API proposal is now attached. I'll start
> working on implementing this next week unless I hear massive complaints.
>
> One detail though: should the enums be declared as is (e g
> "pa_direction_t direction;") or as ints ("int direction;")? I remember
> someone saying enums were more likely to change size than ints.
In line with the client API proposal, here's the matching protocol proposal.
Any objections?
## v25, implemented by >= 2.0
When port availability changes, send a subscription event for the
owning card.
## v26, implemented by >= 2.0
In reply from PA_COMMAND_GET_CARD_INFO (and thus
PA_COMMAND_GET_CARD_INFO_LIST), the following is added:
uint32_t n_ports
...followed by n_ports extended port entries, which look like this:
string name
string description
uint32_t priority
uint32_t available
uint8_t direction
uint32_t n_profiles
string profile_name_1
...
string profile_name_n
Profile names must match earlier sent profile names for the same card.
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
