I do think in order for our Music app to be competitive with alternatives on Android and iOS we need a streaming solution. People have become lazy and expect to be able to play any track without any prior preparation.
Our music app is still like an old mp3 player: plug it in to your laptop, drag some tracks onto the device, listen, repeat. IMHO, most users don't have the patience for even this simple workflow. *W I L S O N P A G E* Front-end Developer Firefox OS (Gaia) London Office Twitter: @wilsonpage IRC: wilsonpage On Fri, Nov 20, 2015 at 6:14 AM, Justin D'Arcangelo <[email protected] > wrote: > Oh wow. This is really awesome! I hadn’t known about this and TBH, we were > under such a short timeline that I doubt we would have had the time to make > a serious attempt at this for v2.5 anyway. > > However, trying to converge towards a standard going forward seems like a > really good idea because that opens the doors for so many more > possibilities (some of which you mentioned). Also, I could see some more > interesting possibilities arise when combining this with FlyWeb. Currently, > our HTTP API is “faked” via bridge.js since we didn’t get ServiceWorkers > for v2.5. But, we can easily remove this “shim” as soon as we get real > ServiceWorkers. The only other limitation with this approach is that the > HTTP API exposed via ServiceWorkers is only available to the content from > the same origin. There is, however, a proposal for something called > “Foreign Fetch” which would expand this to allow content from other > origins: https://wiki.whatwg.org/wiki/Foreign_Fetch > > Now, with FlyWeb, it should be possible to advertise the Music HTTP API > (possibly following the AURA API) to external devices on the local network. > This would enable you to do all sorts of cool things like use the Gaia > Music app on your phone to access a shared music library or a library on > your desktop (like you mentioned). It would also allow you to do the > inverse where you could discover the music library on your phone from > another device (think TV). > > So many cool possibilities! Thanks for sharing this. I will definitely > check this out! > > -Justin > > > On Nov 20, 2015, at 12:48 AM, Andrew Sutherland < > [email protected]> wrote: > > Justin, your mention of the HTTP/RESTy API the revamped music app uses and > the endpoints at > https://github.com/mozilla-b2g/gaia/blob/master/apps/music/js/view.js#L10-L54 > reminded me of a similar effort by the author of the amazing beets "media > library management system" (https://github.com/sampsyo/beets) to create a > standardized/univeral REST API for music libraries. > > It's called AURA, the repo is at https://github.com/sampsyo/aura and the > existing routing table is at > http://auraspec.readthedocs.org/en/latest/http-routingtable.html and the > spec/docs in general are at > http://auraspec.readthedocs.org/en/latest/index.html. > > Do you think it would be feasible to try and converge/help create such a > standard? (Noting that beets has not yet particularly moved forward on > implementing/conforming to the AURA proposal, so AURA could still change > based on guidance/feedback/etc. from Gaia Music.) > > A while back I tried to scratch my own desktop music itch leveraging beets > (http://www.visophyte.org/blog/?p=875), and it would be amazing to me if: > - I could use the existing Gaia Music Player to talk to beets on my desktop > - That if I made a cool new UI, I could use it on my device when beets is > not involved, plus with beets. > > Andrew > > > > _______________________________________________ > dev-fxos mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-fxos > >
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
