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

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.

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

User Interface

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.

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.

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

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

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

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. 1008-1987

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.

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.

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.

Questions?