On Thu, 2011-02-17 at 09:13 +0000, Colin Guthrie wrote: > 'Twas brillig, and Tanu Kaskinen at 17/02/11 07:45 did gyre and gimble: > > Your proposal would probably work well enough in practice, but I still > > would like more an approach where you create a stream and after it gets > > routed you finalize the stream format. > > Yeah, I agree with this statement. It just feels cleaner (my comment > about the format being used in the routing would still be an issue here > but I agree that it was probably an extreme example that wouldn't really > be needed in practice anyway). > > > If routing rules change before > > the format is decided, the daemon can tear down the stream and inform > > the client that it happened because of routing change. The client knows > > now that it should retry. In your proposal the client isn't aware that > > routing rules have changed, so it doesn't know why the connection fails. > > Also, even if connecting succeeds, but with different routing, the > > stream format that the client chooses may be suboptimal. > > > > So, my proposal is the following: > > > > Sinks have a list of format descriptions. One format description is a > > tuple consisting of the encoding type and some parameters that are > > characteristic for that encoding type. Depending on the parameter, a > > parameter value can be a single value, a range, a list or the parameter > > may be unset, meaning that anything is allowed. There should also be a > > special encoding type "any", that means that the client supports > > anything (useful for recording applications that just dump the stream to > > a file). > > > > When a client creates a new stream, it gives a similar list of formats > > as described above for sinks. The list must cover all formats that the > > client can support (usually the list contains only one tuple with only > > fixed parameters). The daemon routes the stream to some sink, and then > > the daemon takes an intersection of the sink formats and the stream > > formats. > > > > If the resulting set contains exactly one fixed format, then that is > > used for the stream. If the set contains more options than one fixed > > format, then the daemon decides the "best" format using some unspecified > > algorithm. If the set is empty, then the stream creation fails. > > When this fails, should we go back to the routing system and ask to be > routed again, but not to this failing sink? I can see this being a) > useful, but b) complicated (not so much complicated on initial > connection but complicated when a stream may get "re-routed" (i.e. when > a new, totally unrelated sink comes along, the routing system may > re-evaluate it's priority lists and try to move the stream to a higher > priority sink (i.e. the one that failed the first time). I probably didn't understand this correctly, but wouldn't this only be helpful if a new sink comes in exactly between when the routing fails and when you retry? -- Arun
