[Rubygems-developers] Network traffic conservation strategies

Gavin Sinclair gsinclair at soyabean.com.au
Mon Mar 29 00:42:34 EST 2004

On Sunday, March 28, 2004, 10:33:46 PM, Chad wrote:

> I'm not exactly sure how this works, but I believe if we set the gem
> client to accept gzip'd streams, apache's mod_gzip (or whatever it's
> called) will automagically kick in and give us some pretty serious 
> compression.  That would probably be a good first step, and then we 
> could judge the need to get smarter later on.  I agree that 500k isn't
> a good amount to be regularly serving or retrieving.

Compressed streams would definitely be a great start.  Using squid
would be excellent as well, although it could be a little tricky.

I have no idea about either of them :)

> While you're in this part of the code, what I think is a bigger problem
> to solve (and maybe you'll have some ideas) is what to do if a gem 
> server is down or a gem isn't found on one server.  A couple of 
> scenarios:

> * hit first source
> * source doesn't respond
> * go to next source
> * it works
> * search and download gem

> * hit first source
> * search for gem
> * requested gem version not found
> * hit next source and do the same?

Funny, I thought those cases were already covered.  It searches all
the available sources, doesn't it?  Anyway, I'll take a look.

> And, should we allow users to point to a specific repository (i.e. gem
> --source=http://chadfowler.com/gems)?  I think so.  We have daydreams
> about adding Rendezvous support for "smart selection" of local 
> repositories.

Yes, we should allow that.  And the specification of sources in the
config file (it's easier to specify an array that way).  I'm afraid I
don't understand what you mean about Rendezvous.


More information about the Rubygems-developers mailing list