Here's my take... it would be great if mime-types solved the problem and if the enclosure "type" attribute was always present and always accurate. These things are not true in the wild world of RSS feeds. The best and most consistent indicator of a file type based on what people actually do is the file extension. It certainly would make things easier if the URL contained an extension at the end... even if it doesn't technically require it. Its not very hard to include &type=.mp4 (or similar) at the end of a redirect URL since that URL is completely arbitrary anyway.
That said, we're working on a solution to this problem that will be available in the next release of FireAnt for Windows (FireAnt for Mac handles it fine). -Josh On 3/17/06, Andreas Haugstrup <[EMAIL PROTECTED]> wrote: > On Fri, 17 Mar 2006 14:35:35 +0100, Michael Sullivan > <[EMAIL PROTECTED]> wrote: > > > it's like this.... tell me if including the media file name, as i > > suggest, > > breaks anything. tell me if it makes a url worse. tell me that it > > makes no > > sense to include the file name. tell me something to convince me that > > this > > suggestion is illogical without telling me 'its not a problem so why fix > > it'. > > You're coming at this from the wrong angle. > > We have URLs and we have HTTP. Well-defined standards and they have been > in use for almost 10 years. You want to change the way the URL work, which > breaks backwards compatibility and *I* am supposed to give you more > reasons not to go ahead? No, you should give *me* a good reason why > redefining the meaning of the URL parts is a good idea. Why should we all > spend time implementing this change when the current system has the same > capabilities? > > Why is this change needed? > How will it break old webpages? > How will differences between the filename part of the URL and the filename > given in the query string be handled? > > The change you're proposing is not simple at all. I still don't know *why* > you want this change. Is it because you're having trouble determining mime > type? In that case use an HTTP library that follows the same standard as > everyone else have been using for the past 10 years - problem solved. No > need for the rest of the world to change. In my last mail I listed the 3 > step process required to determine a mime type in today's web - it's not a > hard thing to do. Or do you have some other reason for proposing the > changes? > > -- > Andreas Haugstrup Pedersen > <URL: http://www.solitude.dk/ > > Commentary on media, communication, culture and technology. > > > > Yahoo! Groups Links > > > > > > > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/videoblogging/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
