[ruby-core:24261] Re: [ANN] meeting log of RubyDeveloperKaigi20090622

I agree pretty much across the board. I was actually hoping that
instead of effort going into a new baked-in sqlite wrapper, that
effort could go into new gem-based FFI sqlite wrapper, which would
benefit many more people than baking it into Ruby 1.9.*. It is true,
it would not benefit everyone, and even where FFI works for JRuby we
still encourage people to use the platform-native options. But if the
question is how to ensure sqlite remains well supported, then the
answer is most definitely not to ship it with Ruby 1.9, since that
just makes Ruby harder to implement on other platforms and runtimes.
An FFI version is at least a better answer.

To be honest, I'd prefer shipping a pure-Ruby SQL implementation that
*everyone* can run on any platform, performance be damned. I think
that would be the Ruby way.

2009/7/10 J=C3=B6rg W Mittag <[e-mail]>:
> Charles Oliver Nutter wrote:
>> On Mon, Jul 6, 2009 at 10:18 PM, Luis Lavena<[e-mail]> wrote=
:
>>> But I still think that bundling sqlite3-ruby into Ruby itself is going
>>> to slowdown the progress and release cycle of the extension, not
>>> taking in consideration it adds another layer of complexity for the
>>> ones that build Ruby from source (me).
>>>
>>> This also will impose a issue for implementations like JRuby, since
>>> this put more work on the team to be able to replicate everything
>>> under the sun of what MRI does.
>> Agreed on both counts. What I'd find a lot more useful is if an
>> FFI-based sqlite wrapper were written, and then everyone can just use
>> the *exact same code*.
>
> Except when they can't. It is true that much more Ruby
> Implementations can support FFI than MRI C Extensions, but there
> are still some implementations that can't support either of
> those. I'm thinking of browser-based implementations like HotRuby
> or Red Sun (or that V8-based one that constantly keeps popping up
> on wishlists, but noone wants to actually write), implementations
> running in limited environments like JRuby/GAE or JRuby/JME-CDC
> and implementations running in "strange" environments like
> BlueRuby.
>
> Also, there are some implementations which run in environments,
> where there already *is* a relational database. BlueRuby can only
> run inside the ABAP VM; the ABAP VM itself is actually not just a
> VM, it is more like an application server, or even an entire
> application stack. And one of the things it includes, is a
> relational database. In fact, the database is so tightly
> integrated, that the BlueRuby Interpreter cannot even read .rb
> text files. If you want to run Ruby code, you have to store it in
> the database as a semi-preparsed structured syntax tree, and the
> BlueRuby Interpreter will load *that* from the database and
> interpret it. In fact, in ABAP there is no filesystem, all I/O
> goes through the database. So, if you add SQLite to Ruby, you
> would have to store the SQLite database file inside a BLOB column
> in the relational database, just so you can get a relational
> database. That's crazy!
>
> However, that is not even the *real* problem.
>
> 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.
>
> I remember you saying at a talk about JRuby something like "the
> good news is, there is a specification for Ruby; the bad news is,
> it is written in C." In this case it is even worse news, because
> not only is the specification written in C, but it is written in
> C *by someone else*, which means that the Ruby Community has
> *no control* over its *own* specification!
>
> Some examples for what it means to make random third-party
> sourcecode part of the Ruby Language Specification: the only way
> for JRuby to become fully compliant with the OpenSSL
> specification was to lock Ola Bini in a dark room with a box of
> Pizza, a crate of Red Bull, a printout of the OpenSSL sourcecode
> and an empty Emacs buffer, and have him transliterate the entire
> codebase line-by-line from C to Java. The only way to become
> compliant with the Ruby 1.9 Regexp specification was for Marcin
> Miel=C5=BCy=C5=84ski to do the same with Oniguruma. What's next, having
> John Lam hand-translate SQLite to C#? Don't these guys have more
> important work to do?
>
>> Please, for Ruby's sake, no more C extensions.
>
> Yes! But also, no more C in the Ruby Specification.
>
> 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) and then allow each individual
> implementation to fulfill this spec in the way they see fit: MRI,
> YARV, Rubinius and tinyrb could use an FFI version of the SQLite
> Ruby wrapper, JRuby and XRuby could use Derby, H2 or HSQLDB (or
> also SQLite-FFI), IronRuby could use, I don't know, Jet maybe,
> HotRuby and Red Sun could use the new HTML5 Offline Storage
> features, MacRuby could use CoreData, MagLev could use a
> relational wrapper around their distributed object store, and
> Blue Ruby wouldn't have to do anything, because it *already* sits
> on top of a relational database.
>
> 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?)
>
> Anyway, I'm not a Ruby Implementer, nor a Ruby Designer, nor a
> Ruby Specification Author, so this is just my 2 cents.
>
> (I *am*, however, a MRI-on-Windows, YARV-on-Windows, JRuby and
> IronRuby user and as such I am painfully aware of the enormous
> problems all that C crap causes.)
>
> Cheers,
> =C2=A0 =C2=A0jwm.
>
>