This could be slightly tricky. For the database, we probably want to use:

• diesel: a Safe, Extensible ORM and Query Builder
• r2d2: a generic DB connection pool
• r2d2-diesel: bridge between those two

Diesel can use multiple database backends, including PostgreSQL. We probably want to use that.

To make the connection pool available to all handlers, Rocket offers a "State" feature.

This is for the far future, but it's kind of important. Things to do:

• Figure out how to run with/without HTTPS in different environments (localhost, server, ...)
• Add certificate and all that jazz to the server
• Configure diesel if necessary
• Set all cookies to secure_only

We probably don't want to write raw CSS...

Rocket offers features to test more easily (click).

Deploying via Heroku kind of works, but here are some nice to haves:

• Deploy to two different heroku uhm... thingies: one for development and one for "release"
• Automatic DB migration handling

Several things we might want to look at:

• Enforce max session lifetime
• Delete all old sessions from a given user on login (avoids multiple session entries per user)
• Set correct cookie properties (lifetime, secure (see #9), ...)
• Maybe manage session ids in a Rust internal collection instead of using the database. This should increase performance, but will invalidate all session cookies when the server is restarted (which is... ok maybe?)

Instead of creating a dedicate issue for each of these, I'll collect ideas for initial development here.

Phase 0 (PR)

• Minor cleanup & merge current progress into master
• Update README.md and CONTRIBUTE.md to reflect the current status of the project
• Make Travis work with diesel.rs and database stuff

Phase 1: User handling (PR)

• DB connection pooling via r2d2 (r2d2-diesel)
• Proper user session cookie
• Proper login page with feedback on failure
• User signup process (postponed: not that important now)
• Maybe add "login via GitHub" (postponed: OAuth API of GitHub needs a fixed URL or something...)
• Rather empty user page

Phase 2: Basic baskets (PR)

• Teach the DB about "baskets"
• List baskets of user on user page & list all existing baskets on the index page (temporary)
• Form to create basket
• Route for page showing the basket's contents (pretty empty at first)

Phase 3: Git

• Create a git repository for each basket
  • probably important: think about where to put the repository
• Show basic git information on basket page
• Make it possible to traverse files of a basket's git repo
  • ... but don't spend too much time on that; this is not really the interesting part of this project. And while file browsing like on GitHub is somewhat needed for the end version, there should be more focus on the "facade" stuff.
  • Maybe even think about making git file browsing just another facade and add multiple item types to a basket... stuff like that
• Think about making the git repository directly accessible
  • ... but again, don't spend too much time on this. If it turns out that a bit more complicated ssh server config is needed, this step should be skipped for now.
• Probably as a requirement for facades and file browsing, I should think about a standard API interface. Of course REST & JSON is a de-facto standard, but it has a number of downsides. Apart from that, I should develop a system which makes it easy to pre render websites when first accessing then AND to update the site via JS by requesting data from the API. This is probably not easy at all, but should lie an important foundation for everything that follows. Keywords: Falcor by Netflix, GraphQL by Facebook.

Phase 4: Facades

• Design the whole thing, basically.
• Make bullet points for "Phase 4" more useful...
• ...

At some time

• Think about testing (click) (Do this rather early!)
• Think about auto deploy to heroku via Travis-CI (see #12)
• Develop a standard style which is similar to GitHub's but still notably different
• Design a logo