-
Notifications
You must be signed in to change notification settings - Fork 222
Google Summer of Code 2014
BrowserFS unifies many sources and sinks of data under a consistent file system abstraction, and exposes this functionality through an implementation of the NodeJS File System API. Using BrowserFS, programs can interface with localStorage, the HTML5 FileSystem, Dropbox, ZIP files, and read-only files available on the HTTP server -- without needing to interface directly with any of these technologies.
These skills apply to all of the ideas below.
- Experience with JavaScript (we actually use TypeScript, but it doesn't take long to learn)
- Familiarity with file systems, and writing programs that interact with them. Especially if you have ever used the NodeJS file system API, or the C API that it is based off of.
BrowserFS is currently compatible with Doppio JVM and Emscripten. As a result, programs written in Java and C/C++ are able to use BrowserFS to interface with many different data storage technologies.
This project would implement a GWT frontend to BrowserFS that allows GWT programs to read and write to the file system. Ideally, the project will implement a portion of the Java File API, allowing existing Java programs that interact with files to interact with BrowserFS using GWT.
The student will need to examine the Java File APIs to determine how we should approach this problem. It's possible that we will be able to reuse portions of the Java Class Library directly, and rewrite parts to make it simpler to implement.
You will need to become familiar with how GWT works, especially its JavaScript Native Interface. You will also need to become familiar with Java's File APIs.
- Experience with Java.
- Experience with GWT.
We currently provide a cloud storage backend for Dropbox. This project would implement a similar backend for Google Drive.
Implementing a backend with read/write support in BrowserFS is actually fairly straightforward. It requires implementing about 10 methods (see the Dropbox backend). This would be the first goal for the project, and is enough work for one summer.
The second goal for the project, a stretch goal, is to make the backend more efficient. There are auxiliary methods that you can implement in order to do this. There are also more advanced optimizations that you can do. For example, you can use Google Drive's support to download only portions of a file to prevent downloading more data than needed.
The main technical challenge in this work will be to learn how to effectively communicate with Google Drive via its RESTful API to list/download/upload/etc. files. Once you learn how to do that, implementing the file system should not be too difficult. BrowserFS provides many useful tools for most of the common tasks that file systems need to do.
- Experience with RESTful web services. The Google Drive API is exposed as a RESTful web service.
BrowserFS has a decently complete unit testing suite, but it does not have any benchmarks to measure its performance. This project would involve:
- Designing and implementing a suite of benchmarks to exercise different file system use cases and scenarios.
- Implementing a benchmark suite runner that can be run automatically.
- The runner should produce benchmark results as a JSON object.
- Running the benchmark suite over a set of past commits to track how BrowserFS's speed has changed over time in multiple browsers.
- [Extra] Design and implement a web frontend that parses the JSON data and presents it in a useful form.
We recommend that the student work backward -- e.g. implement the benchmark suite runner before the actual benchmark suite. A successful student will produce a working benchmark suite runner, and a suite of basic benchmarks.
The main technical challenge is designing and implementing the test suite runner, especially since BrowserFS has many asynchronous APIs. We use a fairly simple system in the test runner that can be reused that involves counting the number of asynchronous API calls that are pending; when the count hits 0, we trigger a callback. Once that issue is surmounted, the next challenge is integrating the benchmark runner into our build system to make it easy to run.
- Experience with writing performance benchmarks.
- Experience with JavaScript build systems (we use Grunt).
- [Extra] Experience with web page design/development.