From: dsafari@...
Date: 2002-10-23T08:26:58+09:00
Subject: Re: RAA.succ?

Quoting Simon Cozens <simon@ermine.ox.ac.uk>:

> why the lucky stiff <ruby-talk@whytheluckystiff.net> writes:
> > I've spent some time reading the CPAN modules to get an idea of how
> > they do mirroring and it just seems to involve FTP sites with
> metadata
> > and modules. I'd love to see us shack up with CPAN because we could
> > certainly build a cool interface on top of the existing
> infrastructure.
> > But I don't think there's enough inertia on our part or theirs to
> make
> > this happen.
> 
> Some ideas from a Perler:
> 
>  I'm not sure that shacking up with CPAN is a great idea, since you'd
> basically have to split the thing down the middle - otherwise you're in
> a mess of name clashes. A better idea might be to grab the code which
> runs
> the CPAN indexes and search.cpan.org and clone off a CRAN or RAA.succ
> or
> something using the same codebase. (Maybe replacing it over time with
> a Ruby version if you're unhappy running Ruby's central repository on
> Perl code...)
> 
>  A single but distributed source for modules is brilliant. If I want a
> Perl module, I know exactly where it'll be; I don't want to be going
> half
> way around the Internet for things. Some hard-core Perlers keep a
> private
> mirror of CPAN themselves so that they know that if at any point they
> need
> additional modules, they've already got them.
> 
>  Indexing and categorizing is good, but one of the biggest problems
> with
> CPAN has been the "official module list". 
> (http://www.cpan.org/modules/00modlist.long.html) CPAN's advantage is
> that
> it's a commons; anyone with an account can upload stuff, and so they
> do.
> You get a lot of junk, but you get a lot of code. The idea of the
> module
> list is to sort out some of the good code from the junk. It doesn't
> work
> because it's a bureaucratic nightmare. A better idea (which is
> basically
> what's happened over time) is to use social pressure to ensure that the
> modules are self-categorizing by careful use of naming.
> 
>  I haven't looked at rpkg yet, but an automated package downloading
> and installing tool is a really big win. Look at Perl's CPANPLUS.pm for
> that.
> 
> Also, look to the Python Vaults of Parnassus for an idea of how *not*
> to
> do things.
> 
> Finally:
>  I think some structured, highly available, distributed repository
> of Ruby libraries with easy client-side installation is crucial to the
> success of Ruby as a mainstream language; it's certainly a key to Perl 
> 5's success.

Hello Ruby folk,

I've written about raa.succ several times in the past and it seems people are
throwing up old ideas that are covered at the rubygarden.org wiki. Let me make
quick reference to these.

http://www.rubygarden.org/ruby?RaaSucc
Here is some notes transcribed by Andy Hunt from discussion at last years Ruby conf

http://www.rubygarden.org/ruby?RaaSuccRequirements
Here is a set of requirements that I collected from Andy's transcription and
added some more of my own wants to it.

http://www.rubygarden.org/ruby?RaaSuccSpike
Here is a small write up of a little experiment with a service based
architecture that I prototyped.

The project is a massive undertaking. I would love to see it have a REST based
API so a large variety of clients can get information out of raa.succ.