FAST - Min Config Server Multi-Session Assembly

Project Overview

The purpose of the Min Config project is to build an iOS app to let users display media (photos and videos) and websites (URLs) easily on the TV using next gen device.

Competition Task Overview

We already have code that works and it consists of two parts:

• server side page that allows users send link, upload photo / video / url and view uploaded content
• client side iOS app that can be used to share video / photo / url to the server

���Users can use this in two different ways:

• Use case 1: Go to the send link page on browser / TV, enter phone number and send a link to the phone, keep the page open in browser. User clicks the link in the phone and it will automatically open the app to let user upload photo / video or share a url. The send link page will display the photo / video / url shared from the app.
• Use case 2: User directly opens the app, clicks Upload on first screen and then the user will be asked to log into their account and choose a device (TV) to upload photo / video / url to. The app basically just sends the "send link page" address to the device and the device will display this page in a browser, so at this point it's basically the same as above. User will see whatever is uploaded from the app on the device.

This all works quite well now, except that the server doesn't support multiple sessions, i.e. if you open the server page on multiple browsers or computers or devices, they will all display the latest upload regardless of which phone the content comes from.

For this contest, we need to improve the server code to support multiple sessions. Here are the detailed requriements:

1. Our latest code is in the topcoder folder: min-config-server is what we need to update in this challenge; MinConfig contains the iOS app code that you should use to help test the server code
2. The client folder contains the server code provided by the client, we'd like to reuse the matcher code in our server implementation since it has better performance and can support multiple sessions. If possible we'd also like to implement the match mechanism, i.e. instead of saving uploaded content to disk and we redirect the upload streams to the get request (viewer page).
3. We want to keep the pages from our current server code unchanged but with the following additional requirements:
   • the send link page will remain the same for send link part
   • currently send link page also serves as the viewer page, we want to break them into two pages: one pages that looks exactly the same as the current send link page but will only be used to send links. We'll need a separate viewer page that's attached to a unique guid (similar to the matcher from client's code)
   • after user sends a link on the new "send link" page, server will automatically redirect the page to a viewer page, such as: <server>/viewer?id=123456, the viewer page will have a single message that says "Waiting for a photo". Note: if link is not successfully sent, the send link page should remain so user can retry until link is successfully sent
   • the app will send photos to the server, including the same id so that the viewer page knows what to display when it detects an upload, i.e. the viewer page should only display uploads that contains the same id, so that uploads from other phones won't be displayed
   • the link sent by the server should include the id as a parameter so the app knows what to include when uploading something
   • for use case 2 this will also work, client app just sends a viewer page url including an id (the app will generate a unique id in this case) to the server, and then uplaod using the same id
4. We anticipate the current server code will need to be updated. Currently it generates a unique token for each phone number and saves that token to data/devices file, and only accepts an upload if the upload includes a token already in the devices file. In the new implementation we will only save the unique token if the SMS is successfully sent, but it will only be used to avoid creating a new is.gd link and will NOT be used to decide whether an upload is aceepted or not. Instead the new viewer page will decide whether an upload is accepted. For example if you upload with id=22232 but there's no viewer page running with this id, the upload will be ignored.

UI

The look & feel of server pages should not change.

TO REVIEWERS

This is a 24h review, make sure you meet the timeline or you will not get good reviewer rating.

You must also provide your own heroku deployment to copilot, you will not get good reviewer rating if you don't provide this.

Technology Overview

• Nodejs
• Twilio
• HTML
• JavaScript

Documentation Provided

Register to download everything from the forum.

Final Submission Guidelines

Submission Deliverables

A complete list of deliverables can be viewed in the TopCoder Assembly competition Tutorial at: http://apps.topcoder.com/wiki/display/tc/Assembly+Competition+Tutorials 

Below is an overview of the deliverables:

• A complete server solution that implements all the mentioned requirements.
• A complete and detailed deployment documented explaining how to deploy the application including configuration information.
• A complete verification doc that shows how the new server implementation works.

Final Submission

For each member, the final submission should be uploaded to the Online Review Tool.