[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LISP - Oracle
- To: Bruce Lester <72110.1107@CompuServe.COM>
- Subject: Re: LISP - Oracle
- From: cfry@MIT.EDU (Christopher Fry)
- Date: Tue, 18 Aug 92 15:05:20 EST
- Cc: info-mcl@cambridge.apple.com, kgrant@us.oracle.com
> I need to generate SQL in MCL 2.0, send it to a remote Oracle database server,
> and parse the result in MCL. I would like MCL to have control of this entire
> transaction.
>
> Has anyone attempted to communicate with Oracle using MCL?
>
> Did anyone attend Cris Kobryn's "Interfacing Lisp to SQL Databases" tutorial
> at the "Second International Lisp Users and Vendors Conference"?
I did. Cris Kobryn works at Harlequin. They make a bunch of add-on Common Lisp
software products intended for multiple hardware platforms.
I don't think they've brought up their SQL interface on the Mac yet.
At the conference, there was a movement to make some CL industry-wide defacto standards
for:
CLIM, Foreign Function Interface, and SQL interface. The plan was not to go through
the whole ansi process at this time, but simply have a generally agreed upon spec by the
major Lisp vendors that would permit users to port their code.
Franz, Lucid, Symbolics, and Harlequin seem to be moving in this direction.
I'm not sure what Apple's plans are but please join me in encouraging
Apple to cooperate here. In particular, a standard FFI to C code
might go a long way toward writing useful portable utilities like an SQL
interface.
For interfacing to particular products like Oracle, its likely that more than one
MCL hacker could make use of such code. If the interface code were portable accross
all CL implementations there might even be a market for such code.
Most likely scenerio is that the company selling the library supports a CL hacker
for doing the interface [typically as part of a project the hacker is doing anyway]
then takes over support and distribution of the interface software. I'd hope the
goal of the company would not be primarily to make money selling the interface code
itself, but rather in gaining more sales for their base product BECAUSE such an
interface was available.
This message is being CC'd to Ken Grant who use to work at my lab [MIT Center for
Coordination Science] and is now at Oracle. One of my predicessors at CCS wrote a
DAL <-> MCL1 interface whose intended use was with Oracle. Due to the cripling
DAL limitation of only 255 bytes per record, the code isn't very useful. A more direct
interface to Oracle would be.
We can save net work to the benefit of all with the right level of cooperation.
You MCL hackers out there that need SQL interfaces, pipe up!