From: Sean Chittenden Date: 2001-11-01T13:33:12+09:00 Subject: [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