On Wed, 2011-02-23 at 01:00 +0530, Arun Raghavan wrote: > On Tue, 2011-02-22 at 13:27 -0600, pl bossart wrote: > > ok. Looks good. > > One last comment on proplists. If we don't define a set of mandatory > > elements, then it's going to be really hard to use this > > pa_stream_new_extended() routine. How will the client figure out what > > exactly it needs to send for each format? > > I was thinking that his would basically develop as convention, though > the few basic properties (rate, channels) could be documented along with > the pa_encoding_t structure. We can document additional properties (for > example bitrate, if some sink ever needs it) as being optional but > recommended if available. The set of parameters can potentially grow forever - we don't know what parameters may become relevant in the future. So, I think we should start by documenting the parameters that we know are important today, and define the approach for adding new parameters in the future. When thinking about handling unknown parameters, there are four cases that need to be considered: 1) A sink has a parameter that a client doesn't understand. 2) A source has a parameter that a client doesn't understand. 3) A playback stream has a parameter that a server doesn't understand. 4) A record stream has a parameter that a server doesn't understand. The cases 2 and 3 should be easy - if the receiver of the data doesn't understand a parameter, it means that it doesn't care. The unknown parameter can be just ignored by the negotiation logic, and the final format should have that parameter removed from the proplist. Cases 1 and 4 are more difficult. One possibility would be to fail the negotiation in such case. That would require that the sender always specifies explicitly all parameters that it knows about, even if it can support anything (IIRC I suggested earlier that a missing parameter would mean that everything is supported). Another possibility would be to try anyway, and the receiver would then kill the stream if the actual payload wasn't satisfactory. What should the negotiation logic do in this case? If the unknown parameter is a fixed value, the parameter should probably be left in the final format proplist. What if the unknown parameter is a range or a list? Maybe the negotiation logic should in this case leave the parameter untouched in the final format proplist. I don't know which approach I like more. The first approach (failing) would be "cleaner", but the second approach (trying anyway) would work in more cases. -- Tanu
