[gnome-db] libgda in Mono

[Rodrigo Moya <rodrigo ximian com>]

Hi

This is a conversation we (people involved in System.Data/libgda
development, gonzalo, tim, danmorg and me) just had in #gnome-db:


<rod_lunch> ok, so here's what I've though :-)
<rod_lunch> we are going to duplicate a lot of work in implementing
native providers in System.Data and libgda
<rod_lunch> as an example, the code danmorg had to borrow from gda-test
<rod_lunch> and this is just the beginning
<rod_lunch> so, I've thought on:
<rod_lunch> adding a System.Data.GDA provider which is just a GDA
binding in C#
<rod_lunch> and make all providers we do use internally that provider
<rod_lunch> the pros are that we write the code once and just do
wrappers
<tim> so System.Data.GDA calls out to libgda?
<rod_lunch> the cons are that we do a couple of extra calls instead of
native calls
<rod_lunch> tim: yes, it doesn't right now, that's my plan
<rod_lunch> the cons are not so much, since now we load .so files
<rod_lunch> so it's almost native
<rod_lunch> but with a couple of extra steps
<rod_lunch> a call to the libgda API, which calls the provider, which
calls the native library
<rod_lunch> so, what do you think?
<gonzalo> well, right now only mysql and postgres are working. So now we
only get mysql for free. Then as we add more providers for libgda we'll
alsi have them for free. It's a good idea.
<rod_lunch> and any objection on the extra step
<rod_lunch> which is just fractions of milliseconds, since they are
direct calls
<gonzalo> about the speed, well, DB access time should take much more
than a few more functions called :)
<rod_lunch> with no conversion
<tim> rod_lunch: what's wrong with the alternative?
<rod_lunch> tim: the alternative is to do the same work on both places
<rod_lunch> of course, if somebody writes a native driver, we'll accept
it
<rod_lunch> but for our work (libgda-mono team) it will make things much
simpler
<rod_lunch> and we'll advance much quicker
<rod_lunch> of course, we'll add anything that is needed to libgda to
support this
<rod_lunch> although it should basically work more or less
<danmorg> gonzalo: i got my gnome cvs account now.  i have no excuse to
start on the oracle provider now ;)
<rod_lunch> danmorg, tim: objections/ideas?
<gonzalo> yuju!
<danmorg> rod_lunch: sounds good
<rod_lunch> tim: in libgda, we've got a lot of code for managing rows,
fields, columns, etc
<rod_lunch> tim: as in System.Data
<danmorg> rod_lunch: have you started it?  like creating a program to
automatically take the libgda headers and create C# pinvokes?
<rod_lunch> danmorg: no, if we agree, that's will be my after-dinner's
task :-)
<rod_lunch> danmorg: although I want to do proper bindings
<rod_lunch> that is, a set of classes in System.Data.GDA that map the
libgda API
<danmorg> rod_lunch: that's find with me if you want to create the
libgda C# bindings.  Shall we call it gda-sharp? hehehe
<rod_lunch> :-)
<gonzalo> heheheh
<rod_lunch> ok, so if we all agree, I'll send mail to mono-list to ask
for objections
<danmorg> cc: gnome-db as well
<rod_lunch> yeah
<rod_lunch> tim: do you agree? :-)
<tim> sorry
<tim> I had somebody come over to my cube 
<tim> what were you saying?  
<tim> it would make for quicker development?
<rod_lunch> yes
<rod_lunch> and a lot of providers supported for free
<tim> it sounds like it would be a good jumping off point to implement
native drivers later
<rod_lunch> yes
<rod_lunch> in fact, I've sometimes thought that libgda future might be
in System.Data
<tim> is that the long term plan?
<rod_lunch> don't know yet
<tim> rod_lunch: that would be sweet
<tim> maybe all of gnome will be headed toward mono?
<rod_lunch> but maybe, if sometime in the future, Mono is THE
development platform
<danmorg> i thought libgda was going to be the basis for
System.Data.OleDb? is that still true?
<rod_lunch> it will make sense to move all libgda to System.Data
<rod_lunch> danmorg: it will be the basis for ALL providers
<rod_lunch> OleDb will just be a wrapper
<danmorg> gotcha
<rod_lunch> and PostgreSQL, MySQL, ODBC, Oracle, etc
<rod_lunch> well, a wrapper and something more
<rod_lunch> to do the specific stuff (send correct connection
parameters, etc)
<rod_lunch> but the real impl will be in libgda, called via
System.Data.GDA

so, this means that all the people involved in system.Data agree in
using libgda for all providers, since it will allow us to reuse a lot of
code that is already written and working. Later on, as I said on IRC,
maybe all the native access will be moved from libgda to System.Data,
but for now, starting like this will make things go much much quicker
than they are, since we are re-implementing a lot of things.

cheers