This is an excellent follow-up Toby - perhaps you can capture your implementation experience on the wiki on a page like "streaming-implementations".
Toby wrote: >However, the percentage of links that actually *include* a 'type' attribute is woefully small. Performing HTTP HEAD requests for each file would be too slow. While I'm not claiming that you are using this as an argument for a new format/value, I will point out that similar forms of argument have been made in the past (and in other forums) for creating new things. The brief point to keep in mind: If existing content publishers are not making use of an *existing* format feature as they should, why would anyone think that such publishers would make any more use of a *new* format feature? And in a proactive way: rather than inventing a new feature for which there is already an existing feature (which may or may not be widely adopted), provide better documentation and how-tos (perhaps with benefits) for how to use that existing feature - as you have recommended in your email. Your solution is good. In addition, we may wish to consider making use of the "type" attribute on a rel="enclosure" links in hAudio a SHOULD to communicate the importance of doing so. Tantek -----Original Message----- From: Toby A Inkster <[EMAIL PROTECTED]> Date: Wed, 20 Aug 2008 16:18:41 To: <microformats-new@microformats.org> Subject: [uf-new] hAudio Issue D4: 2008-01-10 rel-enclosure does not allow forlinks to streaming files Tantek wrote: > Toby wrote: > differentiating between download and streaming URLs > > in the case where both are available. > > That distinction is already made via different MIME types on the > enclosure, reflected in the type attribute (on a or link tags). No > need to invent something new. I've written an hAudio -> M3U converter (M3U is a common playlist format supported by several media players including Winamp, XMMS and iTunes) and do indeed use the 'type' attribute to differentiate between playable downloads (e.g. MP3s, OGGs, etc) and downloads which are not directly playable (e.g. BitTorrent files, ZIP files, etc). This distinction needs to be made in order to avoid placing non- playable files into the playlist. However, the percentage of links that actually *include* a 'type' attribute is woefully small. Performing HTTP HEAD requests for each file would be too slow. One solution of course might be for hAudio to strongly encourage the 'type' attribute to be set on any rel=enclosure links. It would help if all the examples of the Wiki included the attribute, and a list of commonly used MIME types could be provided to help newcomers. (Some are not immediately obvious - e.g. application/ogg instead of audio/ ogg.) -- Toby A Inkster <mailto:[EMAIL PROTECTED]> <http://tobyinkster.co.uk> _______________________________________________ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new _______________________________________________ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new