Skip to end of metadata
Go to start of metadata

This page documents the ongoing work on the Dropbox RO Connector app (known as ROBox) as part of the work on Prototype 1

Overview

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.

Source Code

Proposed Design

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.

Overall

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.

(question) 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.

For example:



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.

Mapping

General Concept

In Dropbox

In ROBox

In RO SRS

Notes

ROs Location

A folder that contains multiple ROs

DropboxResearchObjectContainer object / "ROs Location" in UI

A Workspace

 

RO

A folder within the ROs location folder

ResearchObject object / "Research Object" in the UI

A Research Object

Note the difference between the ROs location folder and a single RO folder within this

RO Manifest

manifest.rdf within RO folder

Cached as part of a ResearchObject object / shown in a structured manner in the UI

manifest.rdf

Assumed to always be at the root of an RO

RO Resources

Files and folders within an RO folder

DropboxEntry objects

Resource files (currently no mechanism for empty folders)

Mimics the exact same layout and structure

Implementation Status

First Iteration

Feature

Implementation status

Testing status

Overall application UI

(tick)

-

Getting Started wizard UI

(tick)

-

Sign in with a Dropbox account

(tick)

(tick)

Store Dropbox account details

(tick)

(tick)

Ask for, store and verify the ROs location folder in the Dropbox

(tick)

(tick)

Dropbox -> RO SRS sync mechanism (in background jobs)

(tick)

(tick)

Sync status dashboard

(tick)

-

My ROs dashboard

(tick)

-

Technical Implementation Details

The application is built using the Ruby on Rails 3 framework.

Bundler is used to manage and load Gem dependencies.

Phusion Passenger (also known as mod_rails) can be used to deploy the application on an Apache based web server.

Development & Deployment Instructions

See the README file in the source repository

Potential Issues

  • 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

    Message from Dropbox staff

    Icon

    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 hash field 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?

Resources

Working with the Dropbox API:

  • No labels