2008/5/12 Rob Rothwell <r.j.rothwell at gmail.com>:
> On Mon, May 12, 2008 at 4:33 AM, Klaus D. Witzel <klaus.witzel at cobss.com>
> wrote:
>>
>> Last night Igor designed the module layer and convinced me that OpenDBX
>> can easily be made an external module (mini-driver) once it's available. Our
>> project intends to support more than just one such mini-driver, loadable on
>> demand. Part of this is Igor's mini-driver API which is all that needs to be
>> adapted for making a new external DB module. And Igor insists on our plugin
>> to manage multiple native threads and their db sessions; wink, blink ;)
>

Yes, that's a needed functionality, because different database
frontends may or may not support threading.
But we want VM to never be blocked by a calls to crappy modules, right? :)

> Wow.  Smalltalk.  Move fast...!
>
> Plugin Name: DBPlugin...maybe this should include an OpenDBX reference since
> it will be based on it?  OpenDBXPlugin?
>
> Package Name: SqueakDB...good
>
> So, if I understand...the design would work like a "meta-db" service that
> would dynamically load new db modules for various databases?  Meaning a
> single service would be handling the Squeak transactions and doling them out
> to the correct mini-drivers?

Yes, and some functionality can be visible at higher levels, so you
potentially can choose what mini-driver to use.

>
> And now, without knowing anything about your design, and probably sounding
> foolish, could your "transaction manager" be written in Squeak itself,
> running headless and passing requests to the appropriate drivers?
>

Not sure what is 'transaction manager' here. But surely, you can make
own abstraction for working with DBs in squeak.
The plugin API should serve as a uniform way for talking with
different DB frontends via minidrivers.

>From my mail to Klaus:

In ST code i can write:

DBManager>>useMiniDriver: aLibraryPath
<primitive: #connectMiniDriver>

this primitive should load a OS shared library, and using known
minidriver API ask for its capabilities and DB types it supports,
so, then users of plugin can write:

self ifWin32: [ driver := DBManager useMiniDriver: 'ADO.dll'. ].
driver enumSupportedDBTypes includes: 'MSSQL' ifTrue: [ .... ]

this will be a low-level support code in ST. A high level code would be

connect: dbType dbHost: ... dbName: ... dbUser: ... dbPass: .. options: ..

or, if users know what they do:

connectUsingLibrary: 'mysqlMiniDriver.so' dbHost: ... dbName: ...
dbUser: ... dbPass: .. options: ..

In this way, we implement plugin once, and as product we having:
- ST package
- plugin
- an API for minidrivers

then developers can implement own minidrivers using pure C - simply by
adopting API with external library they use.

>> Now, unfortunately MS$ is the platform that Rob and Frank want *now* and
>> so OpenDBX is, for a loong, loong time, out of reach for us. This is also
>> the reason behind our project, the *absence* of MS$ platform support.
>
> This is true!
>


-- 
Best regards,
Igor Stasenko AKA sig.