1. Jason Bury Dylan Drake Rush Corey Watt
UT-Drive
Jason Bury
Dylan Drake Rush
Corey Watt

2. Problem (Need)
Professors need a way to share documents and files that doesn’t involve any unknown/foreign hosts (no cloud storage).
Would prefer to host documents on UT servers and share from there.
Needs to be user friendly/easy-to-use so that those without CS backgrounds can utilize it.
Students could use a way to access their U-Drive from anywhere.
Accessing one’s U-Drive is currently a fairly technical task that may be too complex/difficult for non-CS majors.
Some non-command-line interface to access one’s U-Drive would greatly benefit many engineering students.

3. Project Description
Convenient U-drive access from anywhere via web-UI.
Securely and reliably store, retrieve, and share files.
RESTful service (generic, standard API).

4. User Interface

5. Background: Preliminary Design
Server
Run on ECC’s machines.
RESTful.
Client
Installed on users’ machines.
Syncs a folder on user’s machine with a folder on the server.
Background process.
Web UI
Fully functional (no command line necessary), web-based user- interface.

6. Background: REST API
REST is an architecture style for networking applications and software.
Server takes simple http requests containing http commands (PUT, POST, GET, DELETE, etc.) and a uri pointing to a resource.
All of the data needed for a particular command is contained in the http request.
Offers a simplified universal API that anyone can easily hook into.

7. Background: Why REST?
Every action we want to perform is some manipulation of a resource.
Provides several performance-related benefits:
Simplicity
Scalability
Portability
Streamlines design process:
Client-Server separation of concerns
Statelessness

8. Design – RESTful API GET Download file Download zipped directory
Create access link
POST
Login
Upload file/directory
Make new file/directory
DELETE
Delete file
Delete Directory

9. Design Problem Security issues for implementing a client
Potential for a zero-day attack on the runtime environment, the language, or any packages/modules the software relies upon.
Is this really a reasonable concern?
Enter The Heartbleed Bug

10. Testing and Standard Adherence
Plan
Automated testing script.
Test non-trivial methods.
Determine
All variants of the GET and POST command should be tested.
Should also test the cookie creation methods.
Refine
Actually make calls to the server and verify that the calls succeeded.
Design
Create new user on host machine and use it to make test calls. Delete when done.
From ANSI-IEEE Std

11. Integration Plan Install and configure Node.js on ECC hardware:
Acquire zone.
Compile Node.js from source available online.
Install our software:
Install git on zone.
Pull our repo onto the zone.
Run automated tests and then turn our server on.

12. Integration Problem UT servers don’t support the language.
All of ECC’s servers rely on the SPARC architecture.
V8 only supports IA-32, x86-64, ARM, and MIPS instruction sets; does NOT support SPARC.

13. Future Plans
Implement automated testing scripts and verify the software passes our tests.
Publish and provide access to ECC.
Should ECC ever acquire and use a machine with a supported architecture, they will be able to install and use our software with minimal effort.
Publish open-source as well.
Because we are using open-source components in our software, we feel it is only fair to contribute back to the open-source community by providing our code in full. Our code will be made available on github.

14. Questions?