[uf-new] hAudio Issue D4: 2008-01-10 rel-enclosure does not allowforlinks to streaming files

[Tantek Celik]

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 <mail at tobyinkster.co.uk>

Date: Wed, 20 Aug 2008 16:18:41 
To: <microformats-new at 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:mail at tobyinkster.co.uk>
<http://tobyinkster.co.uk>



_______________________________________________
microformats-new mailing list
microformats-new at microformats.org
http://microformats.org/mailman/listinfo/microformats-new