Having web browsers act as personal web servers is a simple and profound technique that will have a big impact on internet music if it becomes common.
One of the major things this makes possible is for web apps to access your own MP3s. So the MP3 is on disk, and is managed by the OS and filesystem, but the software is any web page. This would create very healthy competition among MP3 software, ultimately upping the quality of all player software.
Another big app that this makes possible is HTML pages inside of ZIP files, which is something you’d do if you were using ZIP as an ad-hoc digital packaging scheme. It’s completely possible to use such a file to spread a virus. A clean way to block that attack method is to open the HTML page not via the filesystem but instead via a local web server.
The Opera demos include an app for listening to MP3s on your private PC from a remote location. I don’t think this will be a standard way to listen to music in the long run. You’re not going to keep a web page open all the time, that’s just not how people use the browser. Also, the network connection upstream from your house is too unreliable, and most client OSes are too flaky.
Update: some ideas for hacks
Get asynchronous notifications in web apps, like this:
- AJAX app sends URL of local server to remote server
- AJAX app polls local server
- Remote server eventually POSTS event notification to local server
Why can’t the AJAX app poll the remote server? Either it’s too resource-intensive, because the polling loop is on such a short timer, or it’s too slow, because the timer has been loosened to reduce resource usage.
Another thing you could do is communicate between pages on the same localhost. So for example you have a mail app open in one page and a music app open in another. They could bounce communications across the local server.
Another thing you could do is store remote data on the local machine without inventing a non-RESTful protocol.