[Rubygems-developers] Roadmap for version 0.8.12
chad at chadfowler.com
Mon Jul 18 07:46:14 EDT 2005
On 18-Jul-05, at 1:20 AM, Jim Weirich wrote:
> * topdir
> * yaml (uncompressed source index)
> * yaml.Z (compressed source index)
> * quick
> * index
> * index.Z
> * aaa.gemspec
> * aaa.gemspec.Z
> * bbb.gemspec
> * bbb.gemspec.Z
> * ...
> * gems
> * aaa.gem
> * bbb.gem
> * ...
Maybe now is the time to start using .gz instead of .Z?
> 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
I don't see a reason. The non-compressed yaml index is only still
there to support old clients. We could probably kill it at this
point, I'd think.....but on second though, I just checked the
webalizer stats, and it looks like
a LOT of people are still hitting the yaml file uncompressed.
Tom, are you capturing user agent yet in Apache? We send the
rubygems version as part of user agent, so we could look at this and
see what's hitting /yaml directly.
> (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.
I think it would be good to try it without the single large download
first and see how it goes. It would simplify things if we didn't
have to have a special case.
> (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 would use the gemspec date.
> (3) Unrelated Question:
> I am considering renaming the generate_yaml_index.rb command to
> gem_index (or maybe gem_server_index ... suggestions welcome). This
> bring the command in line with the convention that all gem releated
> command begin with the letters "gem". And it does more then just
> generate yaml, a new name will reflect this better. Any comments?
Another question: could we somehow get gem_server and
gem_server_index to use the same code? I'm afraid we'll end up with
one that works and one that doesn't. And, since fewer people use
gem_server to actually serve gems, we may not notice immediately that
broken. That would be icky.
Overall, this sounds great! I'm finally freeing up a bit, so maybe
we can remote-pair on some of it.
More information about the Rubygems-developers