- From: Danny Ayers <danny.ayers@gmail.com>
- Date: Tue, 12 Oct 2004 18:45:36 +0200
- To: Dare Obasanjo <kpako@yahoo.com>
- Cc: Joshua Allen <joshuaa@microsoft.com>, rdfweb-dev@vapours.rdfweb.org, www-rdf-interest@w3.org, semanticweb@yahoogroups.com, rss-dev@yahoogroups.com, atom-syntax@imc.org
On Tue, 12 Oct 2004 06:58:58 -0700 (PDT), Dare Obasanjo <kpako@yahoo.com> wrote: > > --- Danny Ayers <danny.ayers@gmail.com> wrote: > > > > Lucas Gonze listed the following problems with the > > enclosure element: > > > > 1 It causes users to download big files that they > > will never listen to > > or watch, creating pointless overload on web hosts. > > 2 It doesn't allow us to credit the MP3 host, so we > > can't satisfy the > > netiquette of always linking back. > > 3 For broadband users, MP3s are not big enough to > > need advance caching > > in the first place. > > 4 The required content-type attribute is a bad idea > > in the first place. > > 5 The required content-length attribute should not > > be there. > > > > http://gonze.com/weblog/story/5-17-4 > > I debunked most of these claims at > http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=d9c0205d-3cc1-4efb-a62f-7b0f05fb13af > > 1. The RSS 2.0 spec never describes this automatic > downloading behavior. This was a suggested usage that > Dave Winer began to evangelize outside the spec which > as many have pointed out has its flaws. 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. 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. > 2. This is true, although it did seem like a weird > special case to me. I don't know, with aggregate-republish systems this could get quite common. But whatever, although it's a bit untidy structurally this could be worked around by using the RSS 2.0 <source> element on the item, sort of reverting to the pre-Userland semantics of <description> being the description of an item rather than the item/content itself. > 3. See (1) above > > 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. > 5. Agreed. Cheers, Danny. -- http://dannyayers.com
Received on Tuesday, 12 October 2004 16:45:38 UTC