Re: [RSS-DEV] Re: Atom and RDF

Goodness but this thread has been cc'd shotgun-style out to waaay too many
lists.  How about choosing one and saving the rest from the thread?

> > 1. The RSS 2.0 spec never describes this

That'd be a good starter for most of what that spec discusses...

> The spec-linked "use-case narrative" is rather suggestive. If no
> automatic behaviour is associated with this element then it isn't
> really clear why a separate element is needed rather than a HTML-style
> hyperlink in the content.

Sure there is, an enclosure with a TYPE is a lot more informative than
guesswork associated with an HTML href link.

> But I guess you're right about this not
> really being a format issue, more of a user interface thing - would I
> rather have the (possibly unwanted) mp3 today, or (definitely wanted)
> mp3 tomorrow.

Well, the only tool using it doesn't offer anything in the way of
per-channel or other control over the attachments.  You get 'em all with no
selectiveness.  When there's only attachments coming from one channel and
you know you want it (or narcissus has already assumed you do) then it's
fine.  With many channels or potentially re-aggregated material (lucas'
webjay for example) it's potentially a really horrible waste of bandwidth
all around.

> > 4. No it isn't. Client software should be able, to
> > decide how to react to the enclosure [e.g. if it is
> > audio/mpeg display a play button] without having to
> > make additional HTTP requests to the web server even
> > if it is just HEAD requests.
>
> Hmm, I'm not sure about this at all. I can see how a button might be
> useful, but HTML links don't demand prior notification of the media
> type.

There's a balancing act to be considered here.  One being the idea that
off-peak bandwidth could be used as a way to avoid clogging up the download
time.  This could just as well be handled via other p2 transports
(bitTorrent, ed2k, etc).  However those weren't available (or popular) at
the time the enclosure scheme was foisted onto the spec.  The other being
avoiding needless waste of bandwidth from downloading media that won't ever
be consumed.  This being something the client-side interface could (should)
handle.  Having content type, size and other info greatly aids the client in
being able to make 'smarter' decisions about the content in question.  This
isn't something a regular HREF would usually offer.

-Bill Kearney
Syndic8.com

Received on Tuesday, 12 October 2004 17:52:34 UTC