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

Reply via email to