[ruby-talk:24050] Re: Ruby Gems, rubydoc, and rubynet...

Alright, might as well jump into this conversation and pass along a
message I sent in a private email earlier this week because I think
that this could be a possible alternative format to Gems that seems to
fit the bill of what people here are describing.  This more akin to a
stream of thoughts that I've collected into an email than an
announcement (still getting head back in gear from earlier
distractions).  -sc

[snip]
> Whoa!! Just asking for now. First I have to negotiate to get the name
> back from Addison Wesley. If they agree, then we'll need to work out
> how to turn it into a community site. Any ideas on that?

On how to turn it into a community site, or how to technically
transfer the domain?  ;)

If you're asking about the latter, that's probably the easier of the
two problems.  As for the community site, I started to setup and
design ruby(doc|net).(net|org), which is a hybrid of perldoc, php.net,
and CPAN.

FWIW, here's the 5mile view of things that hopefully will get
explained later:

perldoc -> rubydoc: site for documentation/feedback/contributions
CPAN    -> rubynet: peering and distribution mechanism and module center
php.net -> rubydoc user comments which feed into the downloads/building of modules for rubyet

http://rubydoc.sourceforge.net/
http://rubynet.sourceforge.net/

[snip]
Now that I'm reclaiming my time and about to get my head above water,
I've started to trudge through dig up my ruby(doc|net) work in the
hopes of getting things up and running.  What I'd like to do is
leverage Ryan's Gem format and be able to build Gems on the fly or
nightly (an option for the module maintainer to set when they upload
their module to RubyNet) so that Ruby Gems have the latest
documentation that includes both the documentation supplied by the
author, and by the community at large (something no other language has
at the moment and is an option available at download time.  Community
documentation == user comments, code snippets, etc.).  If you'll
pardon the directory structure/XPath model below (don't know what a
gem looks like internally), I think you'll see how ruby(doc|net) fit
together As I said to Ryan earlier, I don't know how this plays into
the world of Gems, but this is what I've had in mind for the
ruby(net|doc) format.

Each Gem, IMHO, is a complete and independent system much like a UNIX
box and I don't see any reason to not emulate a well understood system
and superb system:


/
/bin        [different entrance points into the Gem file]
/docs
/docs/en    [language specific documentation in the RD format. The rubydoc
/docs/jp     CLI program will use locale information to read the right doc]
/etc        [config file, specifies the default entrance point into the Gem file]
/lib        [shared objects and binary libraries]
/lib/freebsd
/lib/freebsd/3.
/lib/freebsd/4.3
/lib/freebsd/4.4
/lib/solaris
/shared/en  [user comments: this is generated periodically (nightly) via
/shared/jp   a cron job or on post to a module's user documentation area]
/sig        [who says Gems can't have their integrity checked?  MD5s and
             PGP signatures of everything in the module, including comments]
/site_ruby  [OS/locale independent module files]

Like I said, I don't know the internal structure of a gem, but when I
was thinking up rubynet, I was planning on using my own internal
structure which would resemble something similar to that mentioned
above.  With the advent of Gems I don't see any reason to duplicate
work/effort, but no sense in not gathering opinions on the topic.
During the day I work at Cisco and am currently trying to bring ruby
there to replace its perl 4 culture (and subvert the java zealots) and
have a few things that I would like to see incorporated:

1) option of having a Gem decompressed and loaded into RAM for
  access/evaluation (speed issue) or written to disk (ex:
  /tmp/.rubynet_$$).  This would be specified in /etc someplace

2) modules inside of a Gem would be preloaded into RAM (required or
  included at load time) according to a config file in /etc
  (performance win for mod_ruby users)

3) dynamic library search path based on the versions loaded in the
  module versus on the system (if module in system is newer, use
  system library.  Or in an enterprise environment, if major version
  number is different, use the internal module, but if the minor version
  number is greater on the system, then use the system version.).

4) A Gem can be called with different entrance points (programs in
  /bin that are wrappers to functionality in site_ruby).  An example
  would be something similar to:

   In Gem:
	/bin/foo   [default according to conf in /etc]
	/bin/bar

   CLI:
	ruby_gem -s foo some.rbg
	ruby_gem some.rbg        [same as above per the default specified by an /etc directive]
	ruby_gem -s bar some.rbg

4) Configuration directives for the module so that a site maintainer
can tweak critical run-time information in /etc (via a controlled way
that won't break the Gem).

5) Category name-space.  Each module should know where it lives in the
ruby gem name space.  RAA is nice, but a sanctioned board/list that
approves name spaces for modules would go a long way toward making
Ruby a more widely trusted/adopted/maintainable/mature language
(FreeBSD's ports tree and -core team come to mind).  I know some
people won't like this, but it's pretty key for reducing module
overlap and providing a consistent interface to the public (important
here).

As to the original question for the community site?  The ruby
community is about programming, using new modules, _and_ hopefully
about creating a community that provides feedback that is broadly
available for review.  Rubynet to me would provide a list of new
modules that are available, a category browser for looking at modules
in the hierarchy, and a distribution center for all things ruby
(documentation, modules, program updates, etc).

Ruby Doc, on the other hand, is only concerned with the documentation
and feedback of the ruby community.  Free code snippets, etc.
Providing module maintainers with the ability to classify the comments
that their Gem receives is key (code snippet, vs, compliment, etc).
As a system administrator who would install a Gem at a site, I only
want the bare Gem in production, and I want the entire Gem with as
much documentation available for developers.  As a developer, I want
to glean as much code as possible and want to hear about problems that
people have had.  As a Gem maintainer, I'd like to see my work used
and distributed (comment classification and OS/locale independent).
And as the business unit, I'd like to be able to drop off a single
binary file on a remote system and say, "here, use this."

Anyway, I would love some feed back on this.  I'm sure I've left out
some of my thoughts, but there 'ya go.  -sc