allow consumers to specify a mime type for particular URLs #10
Conversation
for reasons beyond a user's control, a particular audio file may not travel with a file extension. This is mostly a use case for streams, for instance at NY Public Radio we serve some streams extension-less, since file extensions are not really enforceable specs, where as content types or mime types are. closes #8
There was a problem hiding this comment.
Having the MIME type white/black lists and the extension white/black lists makes things feel confusing, and I think we could simplify by using only MIME type, and then using an extension-mimetype library on the URL.
https://runkit.com/jeffkeen/57d0348fe81c50140020d425
And in the spirit of making ember-hifi a super simple no-configuration audio library for consumers, I'd prefer to implement a strategy that wouldn't require them to have to specify MIME for the cases where an extension isn't specified.
Right now they'll probably try the simple API (string urls) and if given a URL without an extension, the play will just fail since canPlay will return false, even though one of the our connections could certainly play it.
Since canPlay was put in mainly for performance purposes (so hifi connections wouldn't have to waste time loading audio URLs we know beforehand they can't play), I think it'd be better if we did our best to detect the MIME type on an extensionless URL (mimetype sniffing, perhaps), and if we can't get it then let canPlay return true and allow the connection to try to actually load the audio.
It might be slightly slower for loading a piece of audio, but it's a better experience for getting up and going for an end-user. With a helpful console message we could direct them to specifying the MIME type on an extensionless URL for slightly better performance later on, but I'd like to have that be optional, instead of what is currently required.
this bumps up the importance of mime types in determining playability of a given audio resource and removes canPlayExtension as a method. the whole idea of playability is to improve performance: let a connection specify what it can and cannot play so that we can avoid any extraneous options during `_findFirstPlayableSound`. so we want to continue to allow connection authors a way to specify what will and won't play with their libraries, but still need to ease the burden of mime type knowledge for our service consumers. So if a mime type can not be derived from a given file path, the connection will try to play it anyway, but send a warning to the console leading to documentation explaining the `fileObject` syntax.
basically lifed from https://github.com/jshttp/mime-db
for reasons beyond a user's control, a particular audio file may not
travel over the network with a file extension.
This is mostly a use case for streams, for instance at NY Public Radio
we serve some streams extension-less, since file extensions are not
really enforceable specs, where as content types or mime types are.
closes #8