[Rubygems-developers] Updating source index is slow
Hugh Sasse Staff Elec Eng
hgs at dmu.ac.uk
Wed Nov 10 13:37:23 EST 2004
On Wed, 10 Nov 2004 chad at chadfowler.com wrote:
> Yea, your logic makes sense. It could be that the current code is going
> to be slow whether we download the new index or not. It's definitely not
>> I think we should be using the head method, and the Etag,
>> Last-Modified and any other applicable headers, which really
> I actually tried to do if-modified-since originally, and I ran into
> problems with RubyForge not responding correctly (very weird stuff that
> Tom Copeland and I couldn't figure out). My ruby code was working on
Have you got this recorded anywhere? I've not seen any traffic on
this, and while it may well baffle me as well, there may be some who
recognise what is going on.
> every other server I tried, but I was taking too long to get it to work,
> so Rich stepped in and whipped up the current incarnation. I think using
> If-Modified-Since is the right way to go. We wouldn't actually need to
> use the HEAD method in this case, since the "don't send data" behavior is
> built into the HTTP spec when using If-Modified-Since.
OK. If the resource gets mirrored to a server that only supports
Etag it would be good to have, but YAGNI for now is fine with me.
>>  Please note: I am really in favour of this project, and
>> think criticism that is intended be constructive is a valid part of
>> "first make it work, then make it work right, then make it fast".
> I totally agree. We're in stages 2 and 3 right now.
> We can actually use open-uri with the If-Modified-Since approach. I think
> that would be ideal.
But it won't really support the ETag & size comparison methods, or
will it? Maybe we can just drop those and use If-Modified-Since,
then? Can it support GZIP also? Maybe there's a case for sending
patches for open-uri to the appropriate person, but it's outside the
scope of this project....
> Thanks for your comments and ideas, Hugh.
I'm glad they've been received in the spirit they were intended. :-)
More information about the Rubygems-developers