Hi Nic > > I believe the content description is best done with HTTP and MIME. > > If a file is available in different encoding formats (say > Real or WMV) you should use cool-uris for your media and then > they can be discovered with HTTP. For example consider an > episode of Dr.Who: > > /video/drwho/series1/episode1 > > could be available in WMV and RMA; if the accept header on a > request states the type of content acceptable then the server > can reply with unacepptable (406) if it doesn't have it. > >
I'm a bit concerned about this approach because there are many instances I can think of where you might actually want to know the explicit urls for both types, so that you can represent both in your application. Also, for many users they have the ability to view both kinds of media and as such may want to be given the option rather than forced one over the other. I'd be interested to hear what other's think on this front. >Given all this I believe that enclosures make more sense; MediaRSS is another format duplicating the information from MIME and HTTP and is more difficult to parse. I would point out that MediaRSS allows the content provider to define a lot of meta data about the clip that one can't do via HTTP and MIME. Things like region, duration, copyright information, screen dimension, etc. Thanks for your contribution though, I'll certainly look into the method you have discussed in more detail. What do other people think? Ben - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/[email protected]/
