TomS Words of Wisdom

Thanks for the feedback. Though nobody has yet answered the questions I
posed.

> 1. How many podcatchers would this likely break? i.e. They would not
> ignore the new tags if they didn't support them?
> 2. Who else should I pitch this idea to and where else should this
> idea get discussed?

At this point the "mirror" tags are just an idea. If I still think it's
worth some time and effort after Christmas, I'll flesh out a full spec,
including a valid and commented XML Schema file. [I find schema files
easier to read and there are tools to convert them to DTDs.]

I had somewhat different purposes in mind for each of the three tags.

The main purpose for the "mirror:location" tag is to enable a simple
fall over and/or bandwidth improvement mechanism. This tag is simply a
discovery method that gives the podcatcher and/or user choices in where
to download from in much the same way that Source Forge uses mirrors.
The primary source, i.e. the one given in the enclosure tag itself, may
not be the most efficient for every user. Addressing this problem has
been the traditional function of mirrors since the early days of the
Internet. It's not meant to replace round-robin load balancing.

The "mirror:format" tag is intended to cut down on the number of
separate feeds that need to be maintained and processed. It came out of
some inefficiencies that the FeedMesh guys were complaining about
regarding the same content showing up in multiple feeds with different
UIDs. So the intent is to more closely connect the the content to the
UID. And yes to make use of "mirror:format" tags, the podcatchers have
to allow the user to prioritize format preferences.

Personally I want my podcatcher to download multiple formats and put
them in different places: low-res audio on my 256mb iRiver; high-res
audio on my desktop; low res-video on my video iPod; and HD video on my
DVR. Then when I've consumed the content in one of those locations, my
podcatcher should delete or archive the content from all those
locations. I think that having multiple formats associated with a
single UID in a single feed makes this easier.

Finally the intent of the "mirror:addMirror" tag if to allow mirroring
of content to be collaborative. For example, if I wanted to promote a
new video co-dec, I could offer to trans code a popular video cast and
provide a mirror in the new format without hijacking the main feed.
Another example might be a service that protects against the
slashdot/DSC effect by mirroring the media file as soon as it is
published expecting little or no traffic unless the primary source
becomes unavailable or too slow.

I've done almost no work with XML-RPC I and am still trying to get my
head around exactly how to spec the "mirror:addMirror" tag. Suggestions
welcome.

TTFN
Tom Sayles

> Please forgive the cross-posting and please don't flame me if this subject got hashed out months ago.
>
> I've been kicking around ideas for how to solve some of the bandwidth issues. What I've come up with is proposing yet another name space extension to RSS. Specifically to add /mirror:format, mirror:location/ and /mirror:addMirror/ tags as sub-elements of the enclosure tag. More info and a quick/dirty example are in my blog post at:
>
> http://www.soot-n-smoke.com/tsayles/2005/12/idea-mirror-tags-for-rss-enclosures.html
>
> So I have a couple of questions:
>
> 1. How many podcatchers would this likely break? i.e. They would not
> ignore the new tags if they didn't support them?
> 2. Who else should I pitch this idea to and where else should this
> idea get discussed?
>
> TTFN
> Tom Sayles
>
>