[Rubygems-developers] Why does an install command an update of the Gem source index ?

[Hugh Sasse]

On Fri, 3 Jun 2005, Lothar Scholz wrote:

> Hello,
>
> I'm on a 40Kbit dialup and this is driving me nuts.
> I can't see any need for this update, in fact i don't
> see any need to cache anything from the remote source.

I think you have a point, but I think it would be sensible to cache
the info from the remote source locally.  Rubygems-0.8.10 has a
cache, but it seems to need to figure out whether it is the system
or the user cache, and I've not understood what is happening there
yet.  If it can't write to the system cache then at least reading
from it would help here.  And I don't know if it checks the cache
situation before getting /yaml.Z (index file)

But I think the source_index method in
lib/rubygems/remote_installer.rb should look for a SHA1 sum of
yaml.Z before it decides whether to get it or not. Supporting
If-Modified-Since and/or Etags would help also.  Or it could at
least check that the size hasn't changed.  I'd send a patch but I've
not figured out where the caching comes into play yet.
The SHA1 bit is easy in ruby: the script and the result of feeding it
itself are :-

#!/bin/sh
ruby -r digest/sha1 -e "puts Digest::SHA1.new(File.open('$1', 'rb').read).hexdigest"

3a4b9a45ef044a11661bc5bf92eac3a488eb5186

Once rubygems decides to update then HTTP does allow ranges, but I'm
not sure if partial updates are practical given that we'd have to
store N past versions of /yaml.Z to update against.

> Isn't RubyGems working like a classis client server
> application ?

You mean, it (as|pre)sumes easy availability?
>
>
         Hugh