On 2/27/2011 23:29, Arun Raghavan wrote: > On Sun, 2011-02-27 at 23:20 -0800, Christ Schlacta wrote: > [...] >> mark settings as optional or required for negotiation. if one or the >> other can't support an "Optional" parameter, then it gets replied to as >> unsupported but continuing. a warning is logged. a mandatory option >> will cause it to fail with an error message logged (Warning, Remote sink >> doesn't support required option "bitrate". either upgrade Remote Sink, >> or set bitrate as optional by using "optional bitrate foo") or similar. > We can do this, but what does it really get us? On the sink side, we > know what restrictions we want to place on the input, and it's > reasonable to assume anything unspecified is fine (if it's not, it > should be specified as a restriction anyway). > > On the stream side, we're not providing the information as a restriction > - we're saying "I have this stream, it can be with one of these > formats/properties, find me a sink to plug into". What would an optional > parameter achieve here? > > -- Arun > > _______________________________________________ > pulseaudio-discuss mailing list > pulseaudio-discuss at mail.0pointer.de > https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss the optional parameter says "If you don't have this, it's fine", whereas the mandatory parameter says "If you don't have this, then fail". It allows older and newer software to interoperate, if one end of the connection doesn't know about a parameter, it only matters if it's mandatory. the point of the thread was how to allow future changes of parameters without breaking compatibility.. that would achieve that goal, while allowing the two ends to negotiate when to succeed and when to fail, vs. just always trying or always failing.
