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@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.
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
