[Rubygems-developers] Roadmap for version 0.8.12
hgs at dmu.ac.uk
Tue Jul 19 13:06:31 EDT 2005
On Tue, 19 Jul 2005, Jim Weirich wrote:
> Hugh Sasse said:
>> Normally it will get the main index, and versions in the archive won't
>> show up in that. Any gems in the archive will have their latest
>> versions in the main index, because we preserve the most recent.
>> Anything being got from the archive will thus not be a check for
>> changes, so why bother to transmit the archive index at all?
> Two reasons: (1) Just because the latest version is in the main directory,
> that doesn't mean that the particular version requested is in the archive.
True, it may not exist at all.
> I need to check the index of the archive to know for sure. (2) As
> proposed, the archive directory is a separate, independent source of gems.
> I don't want to develope special case behavior for the archive.
Agreed, except that it *is* a special case for old gems, to stop the
main one filling up. One of the good things about gems is the
usability. I don't think users should have to tell the server to
dig gems out of the archive when the server can figure out that they
are in there. It's too much like having to micromanage the server.
For the person looking for a given gem, the goal is to get the gem,
not to be presenting with information about where it might be
hidden :-) See Donald Norman's stuff about Gulf of Execution.
The main reason for rubygems is to make this kind of thing EASY for
the user, isn't it?
Maybe an option to alter this behaviour is sensible. I have the
feeling I'd want it on by default, and you'd want it off by default.
:-) [Damn! Now I'll never be allowed CVS write access :-)!]
> Keep in mind that not only do I have to grab the index (which doesn't
> exist today), but I also have to grab the individual gemspecs for the gems
> in the archive. Otherwise I can't do dependency analysis.
I concede that :-)
> (Although grabbing the gemspecs on demand might be another interesting
> enhancement ... no, keep is simple for the first revision. We can enhance
> it as needed later)
More information about the Rubygems-developers