From: "NARUSE, Yui" <naruse@...>
Date: 2009-07-12T08:03:28+09:00
Subject: [ruby-core:24273] Re: [ANN] meeting log of RubyDeveloperKaigi20090622

J��rg W Mittag wrote:
> implementations running in "strange" environments like
> BlueRuby.

Ruby is optimized for text processing on POSIX.
Many APIs arround IO reflect this.

So inconsistency on "strange" environments cannot be avoided.
Implementations on such environments should adjust it.

> If you add SQLite to Ruby, whether that be as an MRI C Extension,
> an FFI Extension, a Gem or some other solution, there will still
> be a fundamental problem remaining: the C sourcecode of SQLite
> becomes part of the Ruby Language Specification, at a time when
> the Ruby Community is working very hard on getting *away* from C
> as the specification language for Ruby.

Yes, dependency to SQLite's spec and C source is fundamental problem.

> What would be a better approach is to add a "Ruby Interface For A
> Lightweight Relational Datastore Specification" (maybe similar to
> CoreData, but less, how shall I say this, "NeXTStep-ish") to the
> Ruby Language Specification (plus corresponding Examples in the
> RubySpec suite, of course)

Like HTML5 Structured storage, deciding abstract spec may be good choice.

> Or, we could just do nothing, since SQLite seems to have worked
> quite fine without being included in the stdlib. (I thought the
> general consensus was that we need to *remove* stuff from the
> stdlib, not add even more crap?)

Removing some libraries from bundled libraries is done Ruby 1.9.0.
It is true.

This do nothing option has following problem
* environments where users can't install their own gems
* codes which uses native gems doesn't work on other implementations

-- 
NARUSE, Yui  <naruse@airemix.jp>