Over the last couple of weeks I spent a good deal of time fighting with applet security policies and experimenting with Dropbox uploading/downloading behavior. (I'm also working full time at the NPS developing micro Control Moment Gyroscopes for cubesats, sponsored by the Naval Research Lab and the Air Force Research Lab).
The original intention was to trade messages via Dropbox's sharing protocol. It was an interesting idea, but the reality is that it is a significant abuse of Dropbox and a huge waste of computational resources. However, through the experiments with Dropbox I found the following:
These latencies are too high for the collaborative application I'm working on, and I really hated the idea of abusing Dropbox so violently. Per Calvin's suggestion I'm reworking the idea to be peer-to-peer.
The primary problem with peer-to-peer systems is the lack of a central authority to facilitate their "meeting". For torrent applications, the peers most frequently discover each other's information via central torrent distribution sites. So how can a peer-to-peer collaboration system come to life?
The answer lies within Dropbox:
When you want to edit something collaboratively, cross-platform compatibility is absolutely crucial. This means that every component of the program must run everywhere no matter what. For the User Interface, web browsers are well developed for slick looks and are mostly standardized. For the grunt work below the UI, Java is the only truly cross-platform language. Luckily these two components can be readily combined.
The result is very strange beast indeed. An HTML+Javascript UI (hosted locally) includes a Java applet. The applet manages all the file IO and socket IO with connected peers. So I need a Java applet that does file operations and hosts a peer-to-peer server.
One hidden advantages of the distinct separation between the grunt-applet and the HTML UI is that it allows for extremely clean extensibility and invisible delivery of those extensions. New HTML files containing new/different kinds of editors can be simply added online at the site for my Dropbox app. The Java applet IO/collaborative functionality is completely separate and hidden.
The original intention was to trade messages via Dropbox's sharing protocol. It was an interesting idea, but the reality is that it is a significant abuse of Dropbox and a huge waste of computational resources. However, through the experiments with Dropbox I found the following:
- Dropbox will start uploading a newly created file in about 5 seconds.
- Dropbox will delay starting the upload if it notices the file is being modified.
- Dropbox will generally transfer tiny txt files between connected clients within 12 seconds.
These latencies are too high for the collaborative application I'm working on, and I really hated the idea of abusing Dropbox so violently. Per Calvin's suggestion I'm reworking the idea to be peer-to-peer.
The primary problem with peer-to-peer systems is the lack of a central authority to facilitate their "meeting". For torrent applications, the peers most frequently discover each other's information via central torrent distribution sites. So how can a peer-to-peer collaboration system come to life?
The answer lies within Dropbox:
- User's with shared folders have already committed to equal permissions on those files.
- Connect/disconnect messages are small, infrequent, and can have high latency (e.g. 12 seconds).
- All the files (of all types) that someone would hypothetically want to edit collaboratively are already in their Dropbox folders.
- Security concerns and uploading hassles are diminished.
When you want to edit something collaboratively, cross-platform compatibility is absolutely crucial. This means that every component of the program must run everywhere no matter what. For the User Interface, web browsers are well developed for slick looks and are mostly standardized. For the grunt work below the UI, Java is the only truly cross-platform language. Luckily these two components can be readily combined.
The result is very strange beast indeed. An HTML+Javascript UI (hosted locally) includes a Java applet. The applet manages all the file IO and socket IO with connected peers. So I need a Java applet that does file operations and hosts a peer-to-peer server.
One hidden advantages of the distinct separation between the grunt-applet and the HTML UI is that it allows for extremely clean extensibility and invisible delivery of those extensions. New HTML files containing new/different kinds of editors can be simply added online at the site for my Dropbox app. The Java applet IO/collaborative functionality is completely separate and hidden.
No comments :
Post a Comment