[uf-discuss] The need for a Trackback microformat?

[Kevin Marks]

OK, this brings us to the heart of Podcasting. For much discussion, see 
the last two videos with rel="enclosure" on my blog...

On Dec 3, 2005, at 1:51 PM, Charles Iliya Krempeaux wrote:
> On 12/3/05, Chris Messina <chris.messina at gmail.com> wrote:
>> On 12/2/05, Ryan King <ryan at technorati.com> wrote:
>>> I don't think your relEnclosure and http://microformats.org/wiki/rel-
>>> enclosure are that different, they're just explained differently.
>>> Also, I think they're close enough to be resolved. You want to work
>>> on that?

Yes, the meaning is the same. If we can revise the wording to make this 
clearer, good.

>> Perhaps rel-enclosure doesn't actually make sense long term. Given
>> that relEnclosure, AFAIK, was grafted onto RSS to allow for media
>> being "attached" to feeds, rel-enclosure doesn't make sense in your
>> regular browser-consumed webpages because we've got <embed> and
>> <object>. If RSS had been able to support inline rich media, wouldn't
>> those tags have sufficed?
>
> No.  In RSS, enclosures instruct the client to pre-download the media,
> (but says nothing about "playing" it).  Both <embed> and <object> say
> "play" the media (and say nothing about pre-downloading it AFAIK).
>
> To me, there are 2 orthogonal concepts here.  One is pre-downloading
> it.  And the other is "playing" it.
>
> It was my (perhaps naive) understanding that rel-enclosure was an
> attempt to add pre-downloading to HTML.

It is for pre-downloading, and also to imply synchronisation to a 
non-browser client. The goal is to enable transparent playback of media 
you subscribe to, with no waiting. In other words, the 'playing new 
stuff to me on my bike ride to work' scenario.

>> It also seems that relEnclosure was about behavior on the client side
>> and less about semantics.
>>
>> Let's presume for a minute that we've got infinite bandwidth
>
> If that was the case, then, you would NOT need RSS enclosures.
>
>> and
>> infinite storage. In such a world, all embedded media (and hrefs)
>> would be able to be pulled in and cached automagically. In which case
>> the need for delayed media downloading would be much less, so even if
>> you're syncing your 8,000  feeds,  which all contain rich media like
>> podcasts and vcasts, you would theoretically be able to pull all that
>> data down anyway for later consumption.
>>
>> So the question is, what is the most effective way to link to that
>> media? Indeed, will the media itself supplant the textual content of
>> the feed?

The textual content becomes annotation fro the media, in a podcast, 
which has beneficial effects: it is indexable by search engines and 
other tools that can read HTML (instead of having to spelunk thorugh 
giant binary media files looking for metadata)

>> Will feeds simply become the distribution method for rich
>> media or eventually get into a TV-for-the-web model where you pick
>> people to subscribe to and can "tune in" to an aggregate stream of
>> them whenever you like? I dunno, and I suppose I'm getting a little
>> off topic here.

They already are - see DTV

>> So here's what I'm thinking when it comes down to it (now that you
>> know what I'm looking at in the future)... Shouldn't relEnclosures
>> just be converted to <object> or <embed> tags when they're pulled into
>> xhtml?
>
> I'd say no.

No, that's missing the point.