Skip to content

Home

Jump to bottom
jamesgolick edited this page Aug 7, 2010 · 20 revisions

Motivation

Let’s admit it. RubyForge sucks. It’s been the same for years, has features we don’t need, and is simply not fun to work with. Gemcutter is the answer to these problems. What’s needed for gem hosting done right:

  1. A community-driven effort so it can be constantly improved
  2. A way to browse gems and download them
  3. An easy API to access information and upload/publish gems

The project’s name was originally gemesis, coined by technicalpickles. It seems that a company exists with the same name and a trademark. Hence, a change was necessary. The project was also called gemote for a day, but gemcutter is a lot snappier.

Brainstorming

Let’s use this section for planning out the features of the site, the API, and how it will look.

Site Features

  • Project hosting, limited to:
    • Project description
    • Project page
    • Download gem/tgz per version
    • Hook into GitHub, Lighthouse
  • API driven publishing

REST API Spec

  • /gems/show/my_gem – View the gem “My Gem”
  • /gems/create – Create a new gem (HTTP POST)
- This is not RESTful. In a REST API, the URL is a noun and the HTTP verb is the verb. i.e.:
  • POST /gems – create a new gem
  • GET /gems/my_gem – View the gem “My Gem”

- jamesgolick

Issues

  • Determining who is the project owner. RubyForge does this by manually approving all new projects.
  • Saving and storing gem files, and mirroring content
  • Authentication over API. Should be done via a session key
    • The ability to authenticate over HTTP Basic Auth (via SSL, of course); it follows REST principles and makes API scripting for the client way easier.
    • HTTP is a stateless protocol, and therefore we shouldn’t use sessions. I tend to chuck the user id in a cookie and then sign it so people can’t tamper with it. This also saves a database request every load.

Submit new gem process

  1. User loads “New Gem” page (/gems/new)
  2. User enters Gem Name, Description, and any other metadata, and clicks submit.
  3. Project gets put on waiting list
  4. Application/Admin approves project
  5. Application adds project to list, updating any statistics
    1. Application talks to GitHub API? to create Git repository for project
  6. User receives email confirming the project’s approval
Clone this wiki locally