This is the first stage of my commits for issue #609 that will make the
npm module browserify friendly and browser friendly.
The grunt-browserify module has been introduced to replace
grunt-contrib-concat. Browserify automatically concatenates files and so
there is no need for a concat step.
The faye-websocket module was problematic so I moved the require out to
a separate module within the lib directory. The websocket module is a
folder containing a package.json, directing library consumers to the
entry point that is appropriate for their environment. Browserify picks
browser.js (which simply returns an object holding window.WebSocket)
while everyone else gets the faye-websocket module.
In addition, as browserify handles all the requires, there's no need to
detect the environment or include any pre-built modules. I've removed
the pre-built when and faye-websocket files in favour of letting
browserify use the modules within node_modules. This should make it
easier to maintain dependencies in future versions of this library.
One side effect of this browserify compatibility is that, in order to
allow the library to be globally available in the browser as `Mopidy`,
I've had to set Mopidy as the exported object instead of as a key of the
exported object. To elaborate further, the current API would be like the
following:
var Mopidy = require('mopidy').Mopidy;
However, with this change, the API would be like this:
var Mopidy = require('mopidy');
I'm not sure whether this would be an issue and so I think it's worth
discussing further. It's possible that node developers won't have a
problem but, if they did, a potential workaround within the mopidy.js
file would be:
Mopidy.Mopidy = Mopidy;
This would allow developers to choose either of the following:
var Mopidy = require('mopidy');
var Mopidy = require('mopidy').Mopidy;
Could be a little odd to do this though
When testing the browserify build, I noticed a strange error thrown when
making the initial websocket connection. I managed to track it down to
an IE 'feature' that crops up when you alias in-built functions. In
particular, the when module was aliasing setImmediate to an internal
function (nextTick.) In a newer version of when, the function is
instead aliased to the browserify process.nextTick. This works well
because substack already had that covered.
With when@2.7.0, IE11 appears to be working well. IE10 is still pending
a test.
This adds support for looking up metada for all any any protocols the streaming
backend will support. This should also ensure that file:// files get metadata.
The example is using an Icecast fallback stream that plays a silent MP3 file
when Mopidy sends the shutdown signal.
Tested and found working, however had minor issues with the client
(mpg123) playing the stream was getting out of sync when rapidly changing
songs.
Looking at the Icecast logs, it revealed that the switch between the mopidy and
the fallback stream happened immediately, so the issue is probably with the
client.
- Make attributes internal with _ naming
- Cleanup handling of min durtion. Min set to None disables the check.
- Check state change result for no preroll which indicates a live source which
must transistion to playing to get tags etc.
- Create $XDG_DATA_DIR/mopidy/local in the local extension's validate env.
- Make sure we handle bad data causing ValueError in JSON decoding
- Initializing empty file causes more harm than good as it just leads to a
ValueError. Switched to doing write_library(json_file, {})
- Helpers have been updated to be library oriented, not track. This paves the
way for having {tracks: {uri: ...}, artist: {uri: ...}, ...} type
denormalized data.
- Updates doc references to tag cache
- Removes tag cache from config and marks it deprecated
- Removes tag cache from setup.py
- Removes tag cache from config converter
- Removes tag cache from tests
- Converts local library tests to use JSON.
- Sets local-tagcache as disabled
- Implements new library that uses a gzip compressed json as storage.
- Thanks to reuse of existing serialization code this is a fairly small change.
We now only operate on local track uris, instead of a funny mix of local and
file uris. To achieve this we instead maintain a uri->path mapping to use for
the actual scanning.
- find_uris is no more
- find_files now returns file paths relative to path being searched
- find_files now only works on directories
- find_files tests have been updated to reflect changes
- local scanner has gotten a minimal update to reflect this alteration
