Francois' new music player for remoteStorage
15 views
Skip to first unread message
mic...@michielbdejong.com
Jan 10, 2013, 1:11:50 AM1/10/13
to unho...@googlegroups.com
Francois wrote a music player for remoteStorage:
https://github.com/fkooman/html-music-player
It plays music from the private 'music' module, simply treating directories as album/playlist-trees and files as songs. The filename is
displayed by way of song title, and the directory names are displayed by way of album/playlist title.
You can use http://remotestorage-browser.nilclass.5apps.com/ to upload ogg files into your 'music' folder. Make sure you convert your
music to a format that the html audio tag can read before uploading it. On linux you can use avconv (previously known as ffmpeg) for this.
One consideration is that since music is hosted in the private music folder, and the remotestorage spec
(Internet Draft: https://tools.ietf.org/id/draft-dejong-remotestorage-00.txt ) doesn't support byte ranges, so the player needs to load
the whole file into a blob before it can assign it to the audio tag to start playing. A possible enhancement would be to put the music files
all in a secret directory on /public/music, and then assign the URLs straight to the audio tag's src attribute, which means that the browser
can decide to start playing even though the http request has not fully completed yet. But that's an advanced technical detail.
If you don't have a remoteStorage account yet, you can get one at heahdk.net. Have fun!
Ciao,
Michiel
https://github.com/fkooman/html-music-player
It plays music from the private 'music' module, simply treating directories as album/playlist-trees and files as songs. The filename is
displayed by way of song title, and the directory names are displayed by way of album/playlist title.
You can use http://remotestorage-browser.nilclass.5apps.com/ to upload ogg files into your 'music' folder. Make sure you convert your
music to a format that the html audio tag can read before uploading it. On linux you can use avconv (previously known as ffmpeg) for this.
One consideration is that since music is hosted in the private music folder, and the remotestorage spec
(Internet Draft: https://tools.ietf.org/id/draft-dejong-remotestorage-00.txt ) doesn't support byte ranges, so the player needs to load
the whole file into a blob before it can assign it to the audio tag to start playing. A possible enhancement would be to put the music files
all in a secret directory on /public/music, and then assign the URLs straight to the audio tag's src attribute, which means that the browser
can decide to start playing even though the http request has not fully completed yet. But that's an advanced technical detail.
If you don't have a remoteStorage account yet, you can get one at heahdk.net. Have fun!
Ciao,
Michiel
François Kooman
Jan 13, 2013, 7:01:43 AM1/13/13
to unho...@googlegroups.com, mic...@michielbdejong.com
On 1/10/13 1:11 PM, mic...@michielbdejong.com wrote:
> Francois wrote a music player for remoteStorage:
>
> https://github.com/fkooman/html-music-player
Yes. I initially accepted a pull request from Michiel with the changes
> Francois wrote a music player for remoteStorage:
>
> https://github.com/fkooman/html-music-player
to actually make it use remoteStorageJS. But, that didn't make sense for
quick app development...
So if you want the one that actually uses remoteStorageJS you should use
Michiel's fork: https://github.com/michielbdejong/html-music-player.
Hopefully it will be updated to the latest version of the app soon.
> One consideration is that since music is hosted in the private
> music folder, and the remotestorage spec (Internet Draft:
> https://tools.ietf.org/id/draft-dejong-remotestorage-00.txt )
> doesn't support byte ranges, so the player needs to load the whole
> file into a blob before it can assign it to the audio tag to start
> playing. A possible enhancement would be to put the music files all
> in a secret directory on /public/music, and then assign the URLs
> straight to the audio tag's src attribute, which means that the
> browser can decide to start playing even though the http request
> has not fully completed yet. But that's an advanced technical
> detail.
for instance will not show the duration of the song, even though it
will play. It can be solved for instance by using X-Sendfile in your
remoteStorage server (https://tn123.org/mod_xsendfile/). Very easy to
implement.
Another problem was assigning private files to a <audio> tag. This was
initially done constructing a "Blob" with XMLHttpRequest for which the
Authorization header could be used for retrieving the file. However
the <audio> tag won't send that. The better solution for that is to
use what the OAuth 2.0 Bearer spec implicitly suggests: use the
"access_token" query parameter. This solves the problem in
"standardized" way without needing to resort to (in this case) ugly
Blob hacks.
The above is already implemented in my remoteStorage server [1] and
also in my branch of the html-music-player [2].
Ciao,
Fran�ois
[1] https://github.com/fkooman/php-remoteStorage
[2] https://github.com/fkooman/html-music-player
Michiel B. de Jong
Jan 13, 2013, 11:45:16 PM1/13/13
to unho...@googlegroups.com
Hi!
> So if you want the one that actually uses remoteStorageJS you should use
> Michiel's fork: https://github.com/michielbdejong/html-music-player.
> Hopefully it will be updated to the latest version of the app soon.
Yes, I deployed gh:michielbdejong/html-music-player to
http://music.michiel.5apps.com with 0.7.0-head of three days ago. I will
update it to0.7.0-rc5 as soon as it becomes available (probably this
afternoon).
It is important to note that the current master of gh:fkooman/html-music-player
is *not* compatible with remotestorage and will not work with your remotestorage
account.
> [...] the byte range issues. Firefox
> implement.
Yes, if you control both the app and the server then you can do that, but this is
not part of the remotestorage spec, and apps that require the backend server to
support byte range header should not display a remotestorage logo, to avoid
confusion about what is compatible with what.
> use the "access_token" query parameter. This solves the problem in
> "standardized" way without needing to resort to (in this case) ugly
> Blob hacks.
Again, you are free to write apps that send such query parameters, as long as you call
them "remotestorage-inspired" or something, rather than "remotestorage-compatible".
The behaviour of both remotestorage apps and remotestorage servers is defined by
https://tools.ietf.org/id/draft-dejong-remotestorage-00.txt and nothing else.
We may or may not do a successor version to it in the future if there is a consensus
that the current version is hindering progress, but that will happen at most every 6 months.
We are still recovering from the addition of directory listings, and not even all servers and
apps have caught up with that. Let's stabilize the current spec first in both servers and apps,
then (for the first time!) leave it stable for a few months, and then start discussing possible
necessary improvements.
The query parameter with bearer token is a realistic candidate for making it into the a possible
future replacement spec; the byte ranges a bit less so, but I would say it's at least on the table.
But let's try to get one spec version working on all apps and servers before writing a different
one again.
Let's instead focus on getting all remotestorage servers up to the current spec and getting more
apps onto remoteStorage.js 0.7.0-rc5.
Ciao!
Michiel
> So if you want the one that actually uses remoteStorageJS you should use
> Michiel's fork: https://github.com/michielbdejong/html-music-player.
> Hopefully it will be updated to the latest version of the app soon.
http://music.michiel.5apps.com with 0.7.0-head of three days ago. I will
update it to0.7.0-rc5 as soon as it becomes available (probably this
afternoon).
It is important to note that the current master of gh:fkooman/html-music-player
is *not* compatible with remotestorage and will not work with your remotestorage
account.
> [...] the byte range issues. Firefox
> for instance will not show the duration of the song, even though it
> will play. It can be solved for instance by using X-Sendfile in your
> [http] server (https://tn123.org/mod_xsendfile/). Very easy to
> will play. It can be solved for instance by using X-Sendfile in your
> implement.
Yes, if you control both the app and the server then you can do that, but this is
not part of the remotestorage spec, and apps that require the backend server to
support byte range header should not display a remotestorage logo, to avoid
confusion about what is compatible with what.
> use the "access_token" query parameter. This solves the problem in
> "standardized" way without needing to resort to (in this case) ugly
> Blob hacks.
them "remotestorage-inspired" or something, rather than "remotestorage-compatible".
The behaviour of both remotestorage apps and remotestorage servers is defined by
https://tools.ietf.org/id/draft-dejong-remotestorage-00.txt and nothing else.
We may or may not do a successor version to it in the future if there is a consensus
that the current version is hindering progress, but that will happen at most every 6 months.
We are still recovering from the addition of directory listings, and not even all servers and
apps have caught up with that. Let's stabilize the current spec first in both servers and apps,
then (for the first time!) leave it stable for a few months, and then start discussing possible
necessary improvements.
The query parameter with bearer token is a realistic candidate for making it into the a possible
future replacement spec; the byte ranges a bit less so, but I would say it's at least on the table.
But let's try to get one spec version working on all apps and servers before writing a different
one again.
Let's instead focus on getting all remotestorage servers up to the current spec and getting more
apps onto remoteStorage.js 0.7.0-rc5.
Ciao!
Michiel
François Kooman
Jan 14, 2013, 3:38:27 AM1/14/13
to unho...@googlegroups.com, Michiel B. de Jong
On 1/14/13 11:45 AM, Michiel B. de Jong wrote:
> Hi!
Hey,
> Yes, I deployed gh:michielbdejong/html-music-player to
> http://music.michiel.5apps.com with 0.7.0-head of three days ago. I
> will update it to0.7.0-rc5 as soon as it becomes available (probably
> this afternoon).
That's good to hear!
> It is important to note that the current master of
> gh:fkooman/html-music-player is *not* compatible with remotestorage
> and will not work with your remotestorage account.
Very true. This is due to missing webfinger service discovery support
and the use of "tokeninfo" endpoint by the client to retrieve the userId
at the server instead of asking the user (as part of the user-address).
> Yes, if you control both the app and the server then you can do that,
> but this is not part of the remotestorage spec, and apps that require
> the backend server to support byte range header should not display a
> remotestorage logo, to avoid confusion about what is compatible with
> what.
Actually, this is a server-side only thing. It does not impact the
client app, except that it works much better for (bigger) audio and
video files. This is true for both private and public files...
> Again, you are free to write apps that send such query parameters, as
> long as you call them "remotestorage-inspired" or something, rather
> than "remotestorage-compatible".
Currently I aim my server to be fully remoteStorage compliant. The
server will support the access_token query parameter and the range
requests, but this will not impact the apps that don't use it (i.e.:
remotestoragejs). Except that some things just will work better ;)
> The behaviour of both remotestorage apps and remotestorage servers is
> defined by
> https://tools.ietf.org/id/draft-dejong-remotestorage-00.txt and
> nothing else.
Well, it is not as strict as that I hope. If a server does something not
written in the spec it does not mean that it is no longer compliant.
> We may or may not do a successor version to it in the future if there
> is a consensus that the current version is hindering progress, but
> that will happen at most every 6 months. We are still recovering from
> the addition of directory listings, and not even all servers and apps
> have caught up with that. Let's stabilize the current spec first in
> both servers and apps, then (for the first time!) leave it stable for
> a few months, and then start discussing possible necessary
> improvements.
The problem is, I think, that a spec was drafted without real world
running code. No one can build a usable audio/video player without
violating the spec.
> The query parameter with bearer token is a realistic candidate for
> making it into the a possible future replacement spec; the byte
> ranges a bit less so, but I would say it's at least on the table. But
> let's try to get one spec version working on all apps and servers
> before writing a different one again.
Well, for the music player it is required. So, whether or not the spec
allows for it doesn't make much of a difference to me. I don't really
care not being able to call the music player "remoteStorage" compatible.
As long as my server is... I want an "unhosted" music player, so this
additional functionality is really required :) I do hope there will be a
remoteStorage version of the music player though for those not so
fortunate to use my server ;-)
> Let's instead focus on getting all remotestorage servers up to the
I will definitely work on updating my server to also support webfinger
and be as much as compatible as possible.
Fran�ois
> Hi!
Hey,
> Yes, I deployed gh:michielbdejong/html-music-player to
> http://music.michiel.5apps.com with 0.7.0-head of three days ago. I
> will update it to0.7.0-rc5 as soon as it becomes available (probably
> this afternoon).
> It is important to note that the current master of
> gh:fkooman/html-music-player is *not* compatible with remotestorage
> and will not work with your remotestorage account.
and the use of "tokeninfo" endpoint by the client to retrieve the userId
at the server instead of asking the user (as part of the user-address).
> Yes, if you control both the app and the server then you can do that,
> but this is not part of the remotestorage spec, and apps that require
> the backend server to support byte range header should not display a
> remotestorage logo, to avoid confusion about what is compatible with
> what.
client app, except that it works much better for (bigger) audio and
video files. This is true for both private and public files...
> Again, you are free to write apps that send such query parameters, as
> long as you call them "remotestorage-inspired" or something, rather
> than "remotestorage-compatible".
server will support the access_token query parameter and the range
requests, but this will not impact the apps that don't use it (i.e.:
remotestoragejs). Except that some things just will work better ;)
> The behaviour of both remotestorage apps and remotestorage servers is
> defined by
> https://tools.ietf.org/id/draft-dejong-remotestorage-00.txt and
> nothing else.
written in the spec it does not mean that it is no longer compliant.
> We may or may not do a successor version to it in the future if there
> is a consensus that the current version is hindering progress, but
> that will happen at most every 6 months. We are still recovering from
> the addition of directory listings, and not even all servers and apps
> have caught up with that. Let's stabilize the current spec first in
> both servers and apps, then (for the first time!) leave it stable for
> a few months, and then start discussing possible necessary
> improvements.
running code. No one can build a usable audio/video player without
violating the spec.
> The query parameter with bearer token is a realistic candidate for
> making it into the a possible future replacement spec; the byte
> ranges a bit less so, but I would say it's at least on the table. But
> let's try to get one spec version working on all apps and servers
> before writing a different one again.
allows for it doesn't make much of a difference to me. I don't really
care not being able to call the music player "remoteStorage" compatible.
As long as my server is... I want an "unhosted" music player, so this
additional functionality is really required :) I do hope there will be a
remoteStorage version of the music player though for those not so
fortunate to use my server ;-)
> Let's instead focus on getting all remotestorage servers up to the
and be as much as compatible as possible.
Fran�ois
Reply all
Reply to author
Forward
0 new messages