[DB-SIG] The CORBA DB API fantasy

Andy Dustman adustman@comstar.net
Tue, 16 May 2000 11:14:08 -0400 (EDT)

On Tue, 16 May 2000, M.-A. Lemburg wrote:

> Bill Tutt wrote:
> > You really should read the OLE DB specs. They specify COM interfaces for
> > everything you've specified above and mroe...
> AFAIK, COM is MS centric and I think Andy is targetting Unix
> platforms here as well.

Well, not exactly. I'm targeting all non-MS platforms. :) But seriously,
one of the major design goals of CORBA is platform-independence. Of
course, that's also a goal of Python (or Guido, if you want to argue
semantics). So screw COM.

On Tue, 16 May 2000, Greg Stein wrote:

> .prepare() is simply shifting the time when a prepare is done; it provides
> no advantages over doing the prepare on the first call to .execute() [and
> let additional calls note the same string and reuse the parsed query]

Not necessarily. My thinking on this was that, while prepare() should be a
mandatory part of the API (often doing nothing), it's use in an
application should be optional. Also that cursor.command would be the
prepared query (some kind of object class). But anyway, I'm more
interested in the CORBA DB API fantasy...

On Tue, 16 May 2000, Bill Tutt wrote:
> *sigh* Screw COM. There are two very important concepts with OLE DB that
> make it very powerful. The interfaces that the objects expose, and
> aggregating IUnknowns.
> You can implement these core concepts on any semi-object oriented system. In
> C++, in CORBA, or whatever.
> He was thinking about a blue-sky concept, so I pointed him at what I think
> the blue sky should look like on every platform. :) My top DB API related
> wish is that the core OLE DB libraries were open source, and people could
> use them on Unix or whatever, but it certainly doesn't seem likely to
> happen. Data conversion helper libraries are such a pain in the ass to
> write. :(

Okay, there may be some ideas worth stealing here.

On Tue, 16 May 2000, M.-A. Lemburg wrote:

> Hmm, Andy could probably steal a few ideas from OLE DB and reimplement
> them using CORBA as backend.
> I'm not sure whether it's worth the effort though.

Heh. I think I'd just as soon try to come up with something that wasn't
based on an existing framework, get stuck, and then poke around for some
new ideas.

andy dustman       |     programmer/analyst     |      comstar.net, inc.
telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d
"Therefore, sweet knights, if you may doubt your strength or courage, 
come no further, for death awaits you all, with nasty, big, pointy teeth!"