On Wed, 14 May 2008, Lothar Scholz wrote:
> LL> Mmm, I hardly understand your point, issued the same command here and
> LL> got ackbar spec results in 2 seconds... even with the bulk update...
> LL> and on Windows.
>
> Okay how much data was transfered?
>
> I'm not interested in seconds i'm sure it is the data transfer size
> that kills the performance it. How much data is transfered?
There has been some improvement in this sort of thing over time.
The indices weren't originally compressed, if I recall correctly.
Now they are. I submitted patches to Ruby to get HTTP to use compression
when the server supports it. I think there has been a certain amount
of work done on using the differential features of HTTP to allow transmission
of fragments that changed rather than the whole thing. I don't know
how far that got. And Rubyforge does automatically make use of
mirror sites as well, to try to spread the load So things are improving.
>
> At the moment on my system everything seems to be impossible to
> install anything.
>
> Just because every simple command wants to update my fucking local cache,
> even when i don't see a technical reason why it needs to be updates.
> For example installing a gem where i give the exact version number.
I've not looked at the source recently, and can't remember the details
from when I did, but clearly when no version number is given, the index
must be obtained, to check what the newest is. I suspect that exact
version numbers make use of the same code (because of programmer effort).
> This should just do a http request download a gem file and unpack this
> in the correct places. Where does it need any information about other
> gems?
If the gem is on Rubyforge you can get it "by hand", and then install it.
So you have a workaround for now.
[...]
There have been a lot of pressing issues with rubygems of late
(different platform issues, what to do about case (in)?sensitive
names, etc) so I just think "other wheels are getting the grease"
at the moment. But I don't think the points you raise will go away,
so they will be addressed in due course.
Hugh
_______________________________________________
Rubygems-developers mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rubygems-developers
