My plan was for this next post to explain a little bit about the new software I wrote during my recent break from blogging. It is for building websites. It shares some roots with the software behind this site, except it is more tailored to maintaining large stores of structured data (inventories) then to blogging. And it does one really clever thing I haven't seen before (although, okay, I haven't really examined every other piece of software in this category.)
But instead I want to quickly outline a piece of software that I haven't written, and which is, most likely, beyond my ability to write. Still, sometimes just being able to articulate an idea is a big step.
So again, just to be clear, I have not written this software nor do I have any plans to write it. Probably there would be some legal consequences if someone did write it well enough that it gained any traction. Probably you can already guess I'm talking about some sort of media app. Yes: yet another music jukebox. Now on with the hypotheticals.
It's pretty simple really. Standard WinAmp / iTunes like music player application. The slightly interesting thing is that it works in combination with a server version of the software (there would be a client version and a server version.) You run the client at home.
The client searches your hard drive and indexes all your music files. This meta information is stored in an xml file we'll call music.xml. It also asks you to set an upper limit (in GBs) for the size of your local music library.
The client then sends music.xml up to the server. The server compares this client library - let's call it client_1 - with it's master list, and then replies to the client with a list of all songs in client_1 library that are not already in the server library. The client then begins uploading these songs to the server.
The server also sends a file down to the client - let's say master_music.xml - which is the complete meta information from the giant server library. The client uses this file to create the library displayed in the client app. So the client sees all the music on the server, not just the music on their local machine.
When you press play in the client app it checks to see if the song is in the local library (in music.xml.) If it is then it just plays it. End of story.
If it's not in the local library it connects to the server and streams it from there. If the local library size is less than the max local library size then the stream is also saved to disk locally. If the local library has already reached maximum size, then a song with the lowest play count is erased from the local library (with ties being decided by the additional factor of length of time since last play.) So songs you don't play much - and haven't played a single time recently - are retired from the local library to make way for a new song from the server.
With a modestly fast connection you wouldn't really notice which songs were being streamed and which were playing locally.
The genius here is that people running the application don't have to worry about disk space. And this is a non trivial worry to get rid of for people. If your collection is larger than the largest hard drive (about 400 gigabytes at the moment,) then you know what I am talking about. It just isn't practical for someone to keep a terabyte of files on their home system. For one thing - how are you going to back it up?
If I buy a new disk and want to rip it into my collection I just go ahead and do that. If I am out of room locally the app just clears out some old stuff I don't listen to in order to make room. But that old stuff is still on the server and if I ever want to hear it again I just have to play it once and it will be back on my local machine after being streamed from the server. And, or course, the new disk I just ripped will also be uploaded to the server in the background.
As more clients join the network the central server library grows. Obviously this is the illegal part (assuming you were talking about copyrighted works which is not necessarily clear from this hypothetical post.) I would imagine the server running a giant RAID (probably RAID 5 or RAID 10) for redundancy, with all the clients providing a good bit of offsite backup.
[Technical detail I hadn't thought of yet: the server could create - say every night - a list of songs that were on the server but *not* on any client machine, and then these songs could be synced to an offsite back up machine, or to tape, or to whatever made most sense.]
If a client machine loses it's hard drive then the next time the app is launched the library looks exactly the same. Remember, each client sees the full server library. The only difference here is that each song now played is streamed off the server until the client library is filled back up again.
Similarly (although less likely thanks to the RAID) if the server loses it's library, then when each client app connects again it is asked to start uploading it's whole library, thus automatically rebuilding the central store.
|
But instead I want to quickly outline a piece of software that I haven't written, and which is, most likely, beyond my ability to write. Still, sometimes just being able to articulate an idea is a big step.
So again, just to be clear, I have not written this software nor do I have any plans to write it. Probably there would be some legal consequences if someone did write it well enough that it gained any traction. Probably you can already guess I'm talking about some sort of media app. Yes: yet another music jukebox. Now on with the hypotheticals.
It's pretty simple really. Standard WinAmp / iTunes like music player application. The slightly interesting thing is that it works in combination with a server version of the software (there would be a client version and a server version.) You run the client at home.
The client searches your hard drive and indexes all your music files. This meta information is stored in an xml file we'll call music.xml. It also asks you to set an upper limit (in GBs) for the size of your local music library.
The client then sends music.xml up to the server. The server compares this client library - let's call it client_1 - with it's master list, and then replies to the client with a list of all songs in client_1 library that are not already in the server library. The client then begins uploading these songs to the server.
The server also sends a file down to the client - let's say master_music.xml - which is the complete meta information from the giant server library. The client uses this file to create the library displayed in the client app. So the client sees all the music on the server, not just the music on their local machine.
When you press play in the client app it checks to see if the song is in the local library (in music.xml.) If it is then it just plays it. End of story.
If it's not in the local library it connects to the server and streams it from there. If the local library size is less than the max local library size then the stream is also saved to disk locally. If the local library has already reached maximum size, then a song with the lowest play count is erased from the local library (with ties being decided by the additional factor of length of time since last play.) So songs you don't play much - and haven't played a single time recently - are retired from the local library to make way for a new song from the server.
With a modestly fast connection you wouldn't really notice which songs were being streamed and which were playing locally.
The genius here is that people running the application don't have to worry about disk space. And this is a non trivial worry to get rid of for people. If your collection is larger than the largest hard drive (about 400 gigabytes at the moment,) then you know what I am talking about. It just isn't practical for someone to keep a terabyte of files on their home system. For one thing - how are you going to back it up?
If I buy a new disk and want to rip it into my collection I just go ahead and do that. If I am out of room locally the app just clears out some old stuff I don't listen to in order to make room. But that old stuff is still on the server and if I ever want to hear it again I just have to play it once and it will be back on my local machine after being streamed from the server. And, or course, the new disk I just ripped will also be uploaded to the server in the background.
As more clients join the network the central server library grows. Obviously this is the illegal part (assuming you were talking about copyrighted works which is not necessarily clear from this hypothetical post.) I would imagine the server running a giant RAID (probably RAID 5 or RAID 10) for redundancy, with all the clients providing a good bit of offsite backup.
[Technical detail I hadn't thought of yet: the server could create - say every night - a list of songs that were on the server but *not* on any client machine, and then these songs could be synced to an offsite back up machine, or to tape, or to whatever made most sense.]
If a client machine loses it's hard drive then the next time the app is launched the library looks exactly the same. Remember, each client sees the full server library. The only difference here is that each song now played is streamed off the server until the client library is filled back up again.
Similarly (although less likely thanks to the RAID) if the server loses it's library, then when each client app connects again it is asked to start uploading it's whole library, thus automatically rebuilding the central store.
- jim 6-15-2005 6:29 pm