I just had a conversation with web savvy folks who had never heard of sideloading, so in the interest of spreading a good web meme here's a description:
Scenario 1:
Alice is at home browsing the web and she finds a link to an MP3 which she would like to add to her online music collection. Alice mouses over the link and opens the context menu to find that there is an item which reads "Sideload to Your Music Account". When she chooses that item a window pops open telling her that the MP3 is now sideloading into her account.
Later, Alice finds that her music collection server has fetched the song from where she found it and added it to her collection. The song never passed through her home machine.
Scenario 2:
Bob is surfing the free wireless at a coffee shop in San Francisco when he runs across an image which he would like to blog about. He mouses over the image and opens its context menu which offers an item reading "Sideload to Blog". When he chooses that item a new window opens, showing Bob a new blog post editing window with an automatically generated link to where the new copy of the image sits on his blog service.
The blog service is simultaneously fetching the image from where Bob found it and storing it in his blog space.
Scenario 3:
Nik is at work when he runs across a bit torrent link to a new linux ISO which he wants to install at home. He chooses "Sideload to Home" from the link's context menu, and a window pops open telling him that the sideload has started. Nik then closes the browser window and continues working.
When nik gets home, he finds that his home server has almost completed the bit torrent transfer of the new ISO.
Technology:
The basic system is comprised of a browser plugin and a simple web server application. The browser plugin adds a dynamic item to the context menu when it is popped up over something which can be sideloaded (eg. an anchor or a rendered image). When triggered, the menu item wraps the link href value or the image src value as a parameter to a GET to the web server application.
The url to the web server app might look like this:
http://domain/sideloadPage?destination=account23&type=image&source=http://sourcedomain/path/file.jpg
(url encoded, of course)
The server then starts a thread downloading the sideload source and returns a page telling the user that the sideload has started. The user can then close the browser completely, because the sideload is happening between their service and the file origin.
All the web developers in the audience have already come up with scenarios where this is troublesome. What about links which require a session cookie? What about links which are to dynamic pages in web apps? It's true that there are lots of edge cases which must be handled and no sideloader will handle them all, but having used the i-drive.com (RIP) sideloader for a year I can say that it is very handy for many situations and it is worth showing your users the occasional page explaining why the sideload didn't work.
Finally, at i-drive we realized that when you have 10M accounts there will be a lot of sideloading from the same URLs. There's a new video of a monkey picking his butt, or someone photoshops naked ladies onto horse bodies for that ultimate centaur pic, and suddenly half your users are sideloading the same file. If you build your system so that it keeps track of where files originated, your servers only have to download (and store) the files once, saving you both bandwidth and disk space.
I hope that web app developers out there will consider how they might build sideloading or a technology like it into their applications. It's damn handy and actually helps to reduce network floods.
Comments