Skip to content

Brainstorming

Jump to bottom
qrush edited this page Aug 7, 2010 · 1 revision

This page contains what used to be on the Home page before the project actually got started. It’s here for posterity and reference.

Motivation

Let’s admit it. RubyForge has some serious shortcomings. 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. Don’t be afraid to edit and contribute your thoughts/ideas, that’s what the wiki is for!

Site Features

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

REST API Spec

  • POST /gems – Create new gem
  • GET /gems/my_gem – View the gem “My Gem”
  • GET /gems/my_gem.gem – Download .gem version
  • GET /gems/my_gem.tar.gz – Download .tar.gz version
  • GET /gems/my_gem.zip – Download .zip version
  • PUT /gems/my_gem – Update gem, be it with new files, description, etc
  • DELETE /gems/my_gem – Delete gem

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

Automatic (Github/Gitosis/Gitorious) Gem

  1. When a Git tag matches the regex v0.0.0 ( /v(\d+\.){2,}\d+./ ) that revision is converted to a gem
  2. Maybe a button on the user page “convert now”
    - nofxx

So this would pull down the files and make the server convert them? I’m not sure if I’m cool with this. I’d rather just have the developer do it and then push the gem up. Any other thoughts on this?
- qrush

Notes from boston.rb meeting

  • It’s for gem hosting only. ONLY!
  • Upgrade path should be clear. Remove rubyforge, use gemcutter + github only as primary gem sources.
  • To accomplish this, all rubyforge gems will have to be brought down at first and made available. Essentially a mirror.
  • We’ll have to check rubyforge for new gem updates for gems on a regular interval for gems that haven’t been verified yet.
  • Figuring out who’s the real author of the gem is the real problem
  • One way to do this: author email in gemspec is linked to github username/email, gemcutter sends them a message to verify. (Supposedly, Calendar About Nothing has a similar process)
Clone this wiki locally