This page documents the ongoing work on the Dropbox RO Connector app (known as ROBox) as part of the work on Prototype 1
|Table of Contents|
Dropbox provides a powerful, well known and ready made environment for working with Research Objects (ROs). It is one of many possible environments we can integrate with, but one that we can use to quickly build a prototype around to then elicit user feedback and requirements and evolve the architecture.
For the first prototype, we intend to use Dropbox as the user facing interface for depositing and working with ROs.
The aim is to connect up a user's Dropbox folder, containing these ROs, with the Research Objects Digital Library, which is built on dLibra.
The Dropbox RO Connector app (ROBox) will connect up and manage the synchronisation between the user's Dropbox folder and the backend dLibra store. We will then evolve this as per user needs.
See a full description of the use case.
- ROBox - https://github.com/wf4ever/robox
- RO SRS Client Ruby Gem - https://github.com/wf4ever/prototype1-dlibra-client-gem
The ROBox application will be a web application accessible to users over the internet (e.g.: http://robox.wf4ever.org)
We may want to initially password protect this application whilst we trial it out with our core users.
Users can log in through their Dropbox accounts. The first time this is done, ROBox will store the OAuth tokens for the user's Dropbox so that background synchronisation takes place.
Users can then register their ROs folder (see below for more details).
ROBox will then continually monitor this folder for new and updated ROs and handle synchronisation - changes will be pushed to the RO SRS and updates from the RO SRS will be pulled back into the user's Dropbox folder.
The RO SRS Client Ruby Gem (being developed as part of the ROBox work) will be used to interact with the RO SRS service.
After the first sync, a Dashboard is accessible to the user. Here the user can see the status of their Dropbox ROs folder and see summary information on their ROs.
What else is needed for the Dashboard? We will work with users to find out.
A Getting Started wizard-like page helps the user go through this process. See below for a screenshot:
Working with Dropbox folders and the RO SRS
Users register a single folder in their Dropbox as being their Research Objects store or container, i.e.: the folder in which all their ROs are contained in.
Within this folder, each folder is considered to be a single Research Object.
In the above picture, AstroROs is the folder specified by the user as being their ROs folder. Within this there are three ROs that will be synced with the RO SRS - KpDrop, KpMap and Kptest.
In RO SRS
A folder that contains multiple ROs
A folder within the ROs location folder
A Research Object
Note the difference between the ROs location folder and a single RO folder within this
Cached as part of a
Assumed to always be at the root of an RO
Files and folders within an RO folder
Resource files (currently no mechanism for empty folders)
Mimics the exact same layout and structure
Overall application UI
Getting Started wizard UI
Sign in with a Dropbox account
Store Dropbox account details
Ask for, store and verify the ROs location folder in the Dropbox
Dropbox -> RO SRS sync mechanism (in background jobs)
Sync status dashboard
My ROs dashboard
Technical Implementation Details
The application is built using the Ruby on Rails 3 framework.
Phusion Passenger (also known as mod_rails) can be used to deploy the application on an Apache based web server.
Development & Deployment Instructions
- The Dropbox API does not provide adequate capabilities for synchronisation use cases. They say they are working on this. See for example this forum thread: Use of the API for desktop applications
Info title Message from Dropbox staff
Jiten, web apps are fine. That said, we don't recommend attempting to build apps that do synchronization on the API right now. We haven't yet released primitives that make syncing work in a 100%-robust way.
- Due to the issue raised above (re: synchronisation), we will have to poll the Dropbox API (but not too frequently!) and check for changes. To aid in this, the metadata about a directory contains a
hashfield that changes whenever the contents of the directory change. The API can return back an HTTP 304 when the metadata hasn't changed. See the API doc for this. BUT NOTE: this only tells you when the flat list of files within the directory has changed and does not take into account any nested directories. See this forum thread for more info: iOS: metada hash - strange behavior
- What happens when a user renames/changes their base ROs folder in their Dropbox account?
Working with the Dropbox API: