[icecast-dev] Patches - Was: Stream metadata settings
msmith at xiph.org
Mon Dec 1 16:57:51 PST 2003
On Tuesday 02 December 2003 01:23, Melanie wrote:
> this is the first patch, it implements some basic multilevel fallback
> handling logic, the time window and the no mount option.
> New options are possible within an <mount> section:
> This will allow a source connecting to a mount point to steal the clients
> from it's fallback mount. All clients of the fallback are transferred to
> the pending queue of the newly connected source.
> If the main source drops out, it's clients will, by means of
> <fallback-mount>, be connected to the fallback source. With this turned on,
> when the main source comes back online, the clients will be shifted back on
> reconnect. Without it, the clients will keep listening to the fallback.
These two are the major ones - I think this is a great new feature. However,
we're trying to stabilise for 2.0 in the very near future, so I think this is
probably more suitable for 2.1 (Note: we're hoping that 2.1 won't be long
after 2.0, so this shouldn't delay it TOO long). Obviously, this sort of
thing changes the core server logic quite a bit.
I'd like to see this bit split out from the rest - it's unrelated. That
doesn't mean it won't be accepted, but we'd MUCH rather see patches for one
feature at a time. Could you manage that?
As with the other stuff, documentation is neccesary as well.
<p>> Fallback and reconnect are handled in a multi-level fashion, where each
> fallback may in turn have a fallback. Specifying a circle of fallbacks is
> also possible, however, recovery will not go around the circle more than
> once. There is really no point in doing that, but XML permits it and the
> alternative to making it acceptable would have been to generate a config
> parse error. I didn't really want to add such a showstopper.
> Recovery only scans downward to the first connected source, that is all
> that's needed. By definition, no clients can be connected to lower level
> sources, unless they connected directly, in which case it's ok not to pick
> them up.
This all seems sensible. We need to detect this sort of error at runtime
anyway (not only when reading the config file), since the config can be
modified through the admin interface at any time, so this way of handling it
--- >8 ----
List archives: http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to 'icecast-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body. No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.
More information about the Icecast-dev