[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re2: LISP - Oracle
- To: KLEIMAN@AppleLink.Apple.COM, email@example.com
- Subject: Re: Re2: LISP - Oracle
- From: cfry@MIT.EDU (Christopher Fry)
- Date: Wed, 19 Aug 92 15:41:55 EST
- Cc: KGRANT@US.ORACLE.COM, HARTLEY.AK@AppleLink.Apple.COM, firstname.lastname@example.org
> Date: 19 Aug 92 16:05 GMT
> From: KLEIMAN@AppleLink.Apple.COM (Kleiman, Ruben)
> Subject: Re2: LISP - Oracle
> To: CFRY@MIT.EDU,
> INFO.MCL$@AppleLink.Apple.COM (Macintosh Common Lisp User's Group)
> Cc: KGRANT@US.ORACLE.COM, HARTLEY.AK@AppleLink.Apple.COM (Hartley, Alice)
> CFRY> At the conference, there was a movement to make some CL
> CFRY> industry-wide defact standards for: CLIM, Foreign Function Interface,
> CFRY> and SQL interface. The plan was not to go through the whole ansi
> CFRY> process at this time, but simply have a generally agreed
> CFRY> upon spec by the major Lisp vendors that would permit
> CFRY> users to port their code.
> I agree that a standard API for SQL (and FF access) is essential. However, I
> would NOT like to see it linked with CLIM (not because of any opinions I may
> have about it, but simply because CLIM's objectives are orthogonal, I think, to
> database and foreign function access).
I agree completely. CLIM and SQL should be totally orthogonal. Sorry if I implied
otherwise. On the ohter hand, it may be easier to build a portable SQL interface on top of
a portable FFI so seems to me that that makes sense but is by no means necessary.
> Also, I would like a database-oriented API to also consider transactional
> (e.g., CICS, IMS) and object-oriented (e.g., ITASCA) database management
> systems as well as SQL. Since many of the issues are similar in all of these
> (e.g., security, transaction bracketing), it would at least be possible to
> design an SQL-specific version of the API that is architecturally extensible to
> the others.
This is a bigger project, though it is one that I'm also quite interested in.
In fact, the architecture for the program I'm working on is designed to be able
to use objects stored on several different kinds of databases [SQL, OO,
an-invented-here-flat-file] without caring about which (most of the time).
Certainly to the extent that an SQL DB interface can be generalized, it should be.
email@example.com (Eric Shafto) is interested in this issue. I know of
1 other MCLer in the Boston area [not on the net] too. Combined with Harlequin
[soon to be networked, their new US office is in New Hamshire] maybe we've got