It's an interesting concept.  Convenience and quality are huge factors 
in utility.

The Jakarta commons comes to mind of an interesting model, as well as 
the Apache incubator.

The existense of a target structure for things would be a motivating and 
organizing means for the community as well. In of itself, a project on 
RAA is high-effort/high-risk to use unless I hear frequent mention of 
it. If contained in a pre-validated library, it becomes much more 
comforting to try something out.

Also, a large project can make code more "free" from ownership, which 
can actually be a motivating factor to work on it- the assumption that 
someone owns and is happily working on something isn't there, and there 
is a great sense of potential community benefit to working on something.

It might be worthwhile to late-bind on the naming, or use a code name 
for now. The project might refactor itself in interesting ways.

I heard another response say something about an existing library called 
ruby-sumo. Don't know what that is exactly, but it's a cool handle!

For names, addlib is cute, and works on a few levels,

 From dictionary.com:
adlib- "To improvise and deliver extemporaneously".

I don't mind acronyms for something like this- it'll be fairly 
foundational (I almost said standard :)) so something like nstdlib works 
for me. "extlib" I also like, since it plays on stdlib in C.

The other option is to brand the effort, aka Jakarta from Apache.

Maybe something like "glitter", "shine", "red", "jones", "rubicon" 
(taken, I'm sure by some project), "tuesday" (also taken, I expect),  
"kansas", "toto", "bricks", "blocks", "lumber", "bamboo", etc.

Nick


Gavin Sinclair wrote:

>Hi all,
>
>It's a bit cheeky to call this an announcement, since it's only
>announcing a project idea.
>
>I would like to create a RubyForge project that builds a library of
>useful classes and modules.  That basically describes the standard
>library.  This library wouldn't be standard, hence the name
>"non-standard library".
>
>The purposes of the project:
>
> * collect existing small projects (e.g. Memoize) to ensure their
>   continued maintenance, and hopefully give them higher exposure
>
> * provide a good environment for the development of ADTs, etc.
>   that might otherwise not seem worthwhile due to project
>   management overhead
>
> * provide a rich library that is easy to install and has a high
>   standard of documentation and testing
>
>   * thus, convenience and quality
>
>For example, a very recent thread suggested *replacing* pack and
>unpack with an OO version (Packer and Unpacker classes).  That's a
>radical suggestion that's unlikely to be accepted.  The milder
>approach of providing an OO facade to the existing methods is more
>reasonable, but if accepted, would still take a long time to appear in
>a Ruby release.
>
>On the other hand, inclusion of this idea in a 'nonstdlib' project
>would be feasible and fast.  Before long, you could write in your
>code something like this:
>
>  require_gem 'nonstdlib', '>= 0.3'
>  require 'nonstdlib/packer'
>
>  p = Packer.new
>  p.word 0x01
>  p.word 0x00
>  # etc.
>
>Notice that the version number can be specified to ensure that the
>'nonstdlib' gem has the required feature.  Of course, you can use
>the 'require' line without the 'require_gem' line: RubyGems is not an
>actual dependency here.
>
>The steps to getting this started are:
>
>  1. Get feedback from interested people.
>
>  2. Decide on a name.
>
>  3. Start a RubyForge project and mailing list.
>
>  4. Take it from there.
>
>If there's no interest to start with, I'll just get going.  But this
>sort of thing would benefit from involvement by interested people.
>
>The main thing for now is the name.  That enables the creation of the
>mailing list, on which people can express interest.
>
>I think 'nonstdlib' is a good name.  Anyone got other ideas?
>
>Cheers,
>Gavin
>
>
>
>
>  
>