On Tue, 2011-02-22 at 22:52 +0200, Tanu Kaskinen wrote: [...] > 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. I prefer failing if the pa_stream's properties are not a subset of the properties specified by the sink/source. As Pierre mentions, in the foreseeable we're going to be dealing with a limited number of properties (rate, channels, 2-3 codec parameters), so this approach will work until the requirements change in some fundamental way. Cheers, Arun
