Re: Enclosures, multiple formats

--- In [email protected], Danny Ayers <danny.ayers@g...> wrote:

I was also disappointed by RSS 2.0 approach. My first thought was that
BitTorrent is just another media type and this is just another way of
doing alternative enclosures. 

However thinking about it further, I realized, that while enclosure is
pointing to torrent file, ultimately it is used to download actual
media file. So we dealing with 2 media types here. The torrent file
media type is more of a transport type. BitTorrent could be used to
publish several alternative media types.

So, in addition to alternative enclosure formats, we should be able to
specify
alternative transport methods for them. Having new element/module for
each
transport, as RSS 2.0 proposal does, does not strike me as right
approach.

I like David Janes approach with "link" sub-element for enclosure.
While it is
nice to be able to associate various links with enclosures, I think
delivery
links are of special kind and may need own special element
"transport", instead
of more generic "link" with "rel=delivery". I would also consider
adding "quality" attribute to it to specify preference of various
transport mechanisms.

"transport" element approach is also opens door for handing multiple
mirror
sites, providing same media file, in same format, just from different
geographical
locations. But this needs some further thought.

These are just quick thoughts on the subject. I will think about all
this further and
will try to formulate them in more coherent manner, probably updating
our proposal
with some of these ideas.

However, I am afraid some people taking "simple" approach too far and
will find adding sub-element of enclosure to be too complex. With all
tank about alternative enclosures, and most of proposals suggesting
pretty much the same they go
half (no, even quarter) way and propose quick hack for bittorents. 

Sincerely,
Vadim


> A little update for rss-dev, some pointers from the Podcasting list
> relating to the RSS 2.0 approach to mp3+BitTorrent enclosures. I
> wasn't missing anything, the proposal just takes a rather unexpected
> approach, creating a new namespace and term to support a single
extra
> mime type.
> 
> It seems the reasoning for not using multiple enclosure elements in
an
> item is in part due to the /implication/ in the RSS 2.0 spec that an
> item will only have one <enclosure> element, also because: "I think
> when you go all the way down the multiple enclosures path you'll
have
> completely reinvented the RSS item inside the enclosure (inside the
> item)." [1].
> 
> (I don't actually think anyone was actually suggesting going "...all
> the way down the multiple enclosures path", just multiple elements
> when the same recording was available in different formats/mime
types,
> i.e. mp3 and BitTorrent).
> 
> Anyhow, here are some refs:
> 
> David Janes -
> As you say, in this (http://blogs.law.harvard.edu/tech/rss) all
elements
> that can be repeated (e.g. <item>) are explicitly marked as so. Also
this
> (http://blogs.law.harvard.edu/tech/enclosuresAggregators) says
"allows an
> item to have _an_ enclosure".
> 
> Ross Wm. Rader points to
> http://www.byte.org/index.xml
> 
> which has an item containing multiple <enclosure /> elements.
> 
> David Janes (re-)proposes using an additional link element *inside*
> the enclosure:
> <enclosure
>  url="http://.../sixteen.mp3"
>  length="56248320"
>  type="audio/mpeg">
>   <link:link
>      rel="delivery"
>      type="application/x-bittorrent"
>      url="http://.../sixteen.torrent" />
> </enclosure>
> 
> Jerry Brown points to Ray Slakinski's <podcast:attachment> proposal,
> http://ipodderx.com/podcastRSSModule
> 
> Turns out there is a comment space for Dave Winer's proposal:
> [1] http://www.ipodder.org/2004/11/26#a601
> 
>  
> 
> 
> 
> -- 
> 
> http://dannyayers.com





 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/