[Rubygems-developers] Roadmap for version 0.8.12

Hugh Sasse hgs at dmu.ac.uk
Tue Jul 19 06:24:50 EDT 2005


On Mon, 18 Jul 2005, Jim Weirich wrote:

>
> * topdir
         [...]
>  * quick
>    * index
>    * index.Z
>    * aaa.gemspec
>    * aaa.gemspec.Z
         [...]
>  * gems
         [...]

Agreed.

>
> The main addition is the "quick" directory.  The quick/index file
> contains a list of gems and a MD5 hash of the corresponding gemspec.
> Something like this:
>
>  builder-0.1.1 68673a832739659790fb02e4227d226f

Yes, agree with this, except that I'd go for a stronger hash. MD5 is
regarded as pretty feeble now, and Ruby supports SHA-256. Yes it
is bulkier, but when gems start to get really popular then we will
have some scoundrels trying to abuse the system at some point, so
why make it easier than it needs to be?

         [...]
> in the .gem file.  In particular, the 'files' field is empty.  This
> makes the spec *much* smaller.  Since this copy of the gemspec is only
> used for searches in the cache, omitting this data is not a problem.
         [...]

I remember discussion about this before.  Seems a good idea.
>
> Some open questions:
>
> (A) I show storing both the index and index.Z, both the gemspec and
>    gemspec.Z.  Is there any reason to store the non-compressed
>    version?

Gem_server can generate that if needed?
>
> (B) If there are a *lot* of gems that are out of date, there may be a
>    point were downloading a single, large yaml file may be more
>    efficient than downloading a bunch of smaller files.  At that
>    point we could switch to the current algorithm.

This will only happen when we have mirroring support and people
joining the mirror network, I think.   So for now I'd tend to advise
YAGNI.

>
> (2) Archiving Old Gems
>
> Part of the problem is that one a gem is available on RubyForge, it is
> always available on RubyForge.  The source index keeps expanding and
> expanding.

   "In all of the directions it can whizz" :-)
         [...]

> archive/gem directory.  The archive directory will have its own yaml
> file and quick index (in the format described in part (1) above).

This is a good, pragmatic solution.

> This means that gems moved the archive are still available by using
> the --source option on the command line.  For example, if rails-0.5 is
> in the archive, I can still get it with the command:
>
>  gem install --version=0.5 rails --source=http://gems.rubyforge.org/archive

If the version is less than that in the current repository, the
server should "know" to look in the archive.  After all, all version
numbers are comparables, aren't they?  It is the kind of decision a
computer can make easily, I think.  People won't want to know this
level of detail, IMHO.  Will they want to remember if it is
./Archive, ./archive, ./arch or what?   And to keep up to date with
what has been archived or and what has not?   "Press 8 if your gem
has not been found in the repository."  Please don't inflict that
kind of interface on our users. :-)

> (A) There is a date in the gemspec.  Should the algorithm use the
>    gemspec date, or the date of the file in the file system?

I'd say gemspec date.  If it differs from the file date there's
probably a reason.
>
> (3) Unrelated Question:
>
> I am considering renaming the generate_yaml_index.rb command to
> gem_index (or maybe gem_server_index ... suggestions welcome).  This

gem_index sounds fine.
>
>
>
         Hugh


More information about the Rubygems-developers mailing list