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 <[EMAIL PROTECTED]> wrote:
On 12/2/05, Ryan King <[EMAIL PROTECTED]> 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.
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
