RAA.succ? 
Author Message
 RAA.succ?

I hope there will be some discussion of RAA.succ (or is it RAA.next) at
the upcoming Ruby Conference, but I thought I'd kick-start the discussion
again here...

So what's the latest thinking on RAA.succ?  

I'd definately like to see
some central repository that could be mirrored instead of the current
model where modules actually live on the contributors server (whether at
home or on an ISP) - needless to say, this tends to lead to the
disappearance of packages.

Phil



Fri, 08 Apr 2005 09:37:41 GMT  
 RAA.succ?
Hi,

At Mon, 21 Oct 2002 11:12:49 +0900,

Quote:

> So what's the latest thinking on RAA.succ?  

RAA = "http://www.ruby-lang.org/en/raa.html"
def RAA.succ
  "http://www.ruby-lang.org/cgi-bin/cvsweb.cgi/app/raa/"
end

--
Nobu Nakada



Fri, 08 Apr 2005 10:27:34 GMT  
 RAA.succ?
Hi,

Quote:

> Sent: Monday, October 21, 2002 11:28 AM
> > So what's the latest thinking on RAA.succ?  

> RAA = "http://www.ruby-lang.org/en/raa.html"
> def RAA.succ
>   "http://www.ruby-lang.org/cgi-bin/cvsweb.cgi/app/raa/"
> end


a little old and rickety.  We will replace RAA in this
or next week.

Changes:
- lightweight top page
- iso8859-1 => UTF-8
- added simple keyword search
- show projects by the specified owner

..that's all.

SOAP and XML-RPC interfaces will be updated, too.

Regards,
// NaHi



Fri, 08 Apr 2005 16:03:34 GMT  
 RAA.succ?

Quote:

> I'd definately like to see
> some central repository that could be mirrored instead of the current
> model where modules actually live on the contributors server (whether at
> home or on an ISP) - needless to say, this tends to lead to the
> disappearance of packages.

This sounds similar rpkg:

http://www.ruby-lang.org/en/raa-list.rhtml?name=rpkg

~ Patrick



Sat, 09 Apr 2005 02:59:23 GMT  
 RAA.succ?

Quote:



>> I'd definately like to see
>> some central repository that could be mirrored instead of the current
>> model where modules actually live on the contributors server (whether at
>> home or on an ISP) - needless to say, this tends to lead to the
>> disappearance of packages.

>This sounds similar rpkg:

>http://www.ruby-lang.org/en/raa-list.rhtml?name=rpkg

No doubt rpkg should be part of raa.succ, but it still doesn't address the
need for a central, mirrorable repository for packages/modules/snippets.  
Just this morning there was a message on the list about someone not being
able to find the FastCGI module - the link given on the RAA is now dead.  
This is a _major_ problem!  Until we have a central repository that is
mirrored we have to face the fact that the RAA is just a list of pointers
to potentially non-existent locations.  Key packages can (and do) just
disappear when someone's webserver goes away or when someone moves to
another ISP.

It might be an interesting exercise to write a script that tries to get
to all the links on the RAA to see how many of them are still active.

In regards to rpkg: Is it going to be included in Ruby's standard
libraries?  I tend to think this needs to happen in order for it to become
widely used.  Newbies may not know much about downloading and installing a
package.  Others may not have root access on their machines.  If it comes
with Ruby then it's more likely to become widely used.

Phil



Sun, 10 Apr 2005 00:56:32 GMT  
 RAA.succ?

Quote:

>Hi,


>> Sent: Monday, October 21, 2002 11:28 AM

>> > So what's the latest thinking on RAA.succ?  

>> RAA = "http://www.ruby-lang.org/en/raa.html"
>> def RAA.succ
>>   "http://www.ruby-lang.org/cgi-bin/cvsweb.cgi/app/raa/"
>> end


>a little old and rickety.  We will replace RAA in this
>or next week.

>Changes:
>- lightweight top page
>- iso8859-1 => UTF-8
>- added simple keyword search
>- show projects by the specified owner

Those are all great changes, but it still doesn't address the fact that
the RAA is just a list of links to potentially non-existent locations.  
Key packages could be lost after their creators loose interest.

The RAA needs a change in structure not just a change of interface.  When
someone creates a module they
want to put on the RAA  they should actually upload that module code
to the RAA server where it then resides.  There should also be at least one
mirror of the RAA repository.  This (as I recall) is the way CPAN works -
it guarantees that crucial modules will not just disappear when someone
changes ISPs or looses interest.  You'll always be able to get a
particular module from the RAA or it's mirror(s).

There are packages now listed on the RAA that no longer exist - someone
wrote about not being able to find FastCGI this morning.  I also tried to
get an extension for top that no longer is available.  I'm sure there are
other dead links on the RAA and it's only gonna get worse as time goes on.

Phil



Sun, 10 Apr 2005 01:10:22 GMT  
 RAA.succ?
Hi,

In message "Re: RAA.succ?"

|Those are all great changes, but it still doesn't address the fact that
|the RAA is just a list of links to potentially non-existent locations.  
|Key packages could be lost after their creators loose interest.
|The RAA needs a change in structure not just a change of interface.

OK, OK.  Let me clarify.

We really need a new RAA with better interface.  This is what Nahi and
others are working on.

We also need something like CPAN for Ruby, aka RAA.succ.  But it
requres much work and time.  So we go step by step.

                                                        matz.



Sun, 10 Apr 2005 02:27:29 GMT  
 RAA.succ?
Hi,
I agreed with Phil that the code should be stored on RAA Servers.
I got some modules/classes that I would like to share, but I do not have
a web page.


Quote:
-----Original Message-----

Sent: Tuesday, October 22, 2002 1:38 PM
To: ruby-talk ML
Subject: Re: RAA.succ?



>Hi,


>> Sent: Monday, October 21, 2002 11:28 AM

>> > So what's the latest thinking on RAA.succ?  

>> RAA = "http://www.ruby-lang.org/en/raa.html"
>> def RAA.succ
>>   "http://www.ruby-lang.org/cgi-bin/cvsweb.cgi/app/raa/"
>> end


>a little old and rickety.  We will replace RAA in this
>or next week.

>Changes:
>- lightweight top page
>- iso8859-1 => UTF-8
>- added simple keyword search
>- show projects by the specified owner

Those are all great changes, but it still doesn't address the fact that
the RAA is just a list of links to potentially non-existent locations.  
Key packages could be lost after their creators loose interest.

The RAA needs a change in structure not just a change of interface.
When
someone creates a module they
want to put on the RAA  they should actually upload that module code
to the RAA server where it then resides.  There should also be at least
one
mirror of the RAA repository.  This (as I recall) is the way CPAN works
-
it guarantees that crucial modules will not just disappear when someone
changes ISPs or looses interest.  You'll always be able to get a
particular module from the RAA or it's mirror(s).

There are packages now listed on the RAA that no longer exist - someone
wrote about not being able to find FastCGI this morning.  I also tried
to
get an extension for top that no longer is available.  I'm sure there
are
other dead links on the RAA and it's only gonna get worse as time goes
on.

Phil



Sun, 10 Apr 2005 03:17:52 GMT  
 RAA.succ?

Quote:

> Hi,
> I agreed with Phil that the code should be stored on RAA Servers.
> I got some modules/classes that I would like to share, but I do not have
> a web page.



There's always sourceforge. :)

Regards,

Dan



Sun, 10 Apr 2005 04:31:02 GMT  
 RAA.succ?

Quote:

> Those are all great changes, but it still doesn't address the fact that
> the RAA is just a list of links to potentially non-existent locations.  
> Key packages could be lost after their creators loose interest.

Phil (and others in this thread),

I would like to help start a group of mirrors.  I have space I can
contribute and I'm sure there's a wealth of others in this community
who can offer mirroring space.  And the more we spread the bandwidth, the
less we'll each actually have to give.  (It would actually be quite cool
for someone to write a Ruby P2P app that could help people set up
part-time mirrors on their desktop or server!)

The thing is: no one seems to know the future of RAA.succ, so adding
mirrors to an uncertain project is a waste of time.  We either need
to see the prevailing projects duke it out (rubynet vs. rpkg) or we
could support both for a time.

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.

My feeling is that we should start mirroring the rpkg effort.  It's a
working project.  It seems with RAA.succ that the urge is irresistible
to start something new all the time.  Rather, let's pick a project to
support and make it happen.  Or make both happen.  I don't see the specifics
of implementation (rubynet vs. rpkg) being as big of a deal as just
forming the league of mirrors which can help us preserve RAA as soon
as possible.

_why



Sun, 10 Apr 2005 05:59:29 GMT  
 RAA.succ?

Quote:
> 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.*-*-*.com/ ) 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.

--
"If you do not wish your beer to be served without the traditional head,
please ask for a top-up". With the subtext: "Your traditional head will
then exit via the traditional window. Arsehole".
    - Mark{*filter*}erson



Sun, 10 Apr 2005 06:16:12 GMT  
 RAA.succ?

Quote:

> So what's the latest thinking on RAA.succ?  

CPAN was good, very good when it was little.

But now it is bad, very bad.

Why?

Because you can get stuck in a _very_ extended upgrade cycle as soon as
you start sucking on any one package! Even worse the cycle is not
gauranteed to land you with a mutually compatible set of module versions!

What really is needed is a "Batteries Included" ruby distribution that
will have all (reasonably) prime time RAA modules at the latest (mutually
compatible) version.

Advantages...
  1) user probably doesn't need to go to RAA for 99% of cases, he got it
     all with his distro.
  2) The versions are mutally compatible and have been unit / integration
     tested together.
  3) You can trivially "freshen" your distro from CVS.

--

John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632

New Zealand

Good Ideas:
Ruby                 - http://www.*-*-*.com/ - The best of perl,python,scheme without the pain.
Valgrind             - http://www.*-*-*.com/ ~sewardj/ - memory de{*filter*} for x86-GNU/Linux
Free your books      - http://www.*-*-*.com/



Sun, 10 Apr 2005 07:22:18 GMT  
 RAA.succ?

Quote:

> > 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.



Sun, 10 Apr 2005 07:26:58 GMT  
 RAA.succ?

Quote:

> Because you can get stuck in a _very_ extended upgrade cycle as soon as
> you start sucking on any one package! Even worse the cycle is not
> gauranteed to land you with a mutually compatible set of module versions!

I've never had that happen. Can you give an example?

Quote:
> What really is needed is a "Batteries Included" ruby distribution that
> will have all (reasonably) prime time RAA modules at the latest (mutually
> compatible) version.

Who defines the best?

--
The complex-type shall be a simple-type.  ISO 10206:1991 (Extended Pascal)



Sun, 10 Apr 2005 07:32:08 GMT  
 
 [ 86 post ]  Go to page: [1] [2] [3] [4] [5] [6]

 Relevant Pages 

1. good link to read as we contemplate RAA, RAA.succ, et al

2. raa.succ - independent reviews

3. More RAA.succ ponderings

4. raa.succ status?

5. RAA.succ

6. raa.succ top 5!

7. RDE (was RE: RAA.succ (?))

8. RAA.succ (?)

9. RAA.succ

10. mkmf.succ() == MfMaker ?

11. String#succ w/non-alphanumeric strings

12. Attribute Question T'SUCC

 

 
Powered by phpBB® Forum Software