home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / lisp / mcl / 1275 < prev    next >
Encoding:
Internet Message Format  |  1992-08-19  |  2.8 KB
  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!mips!sdd.hp.com!elroy.jpl.nasa.gov!ames!data.nas.nasa.gov!taligent!apple!cambridge.apple.com!cfry@MIT.EDU
  2. From: cfry@MIT.EDU (Christopher Fry)
  3. Newsgroups: comp.lang.lisp.mcl
  4. Subject: Re: Re2: LISP - Oracle
  5. Message-ID: <9208191940.AA21371@MIT.EDU>
  6. Date: 19 Aug 92 20:41:55 GMT
  7. Sender: info-mcl-request@cambridge.apple.com
  8. Lines: 40
  9. Approved: comp.lang.lisp.mcl@Cambridge.Apple.C0M
  10. Original-To: KLEIMAN@AppleLink.Apple.COM, shafto@aristotle.ils.nwu.edu
  11. Original-Cc: KGRANT@US.ORACLE.COM, HARTLEY.AK@AppleLink.Apple.COM,
  12.         info-mcl@cambridge.apple.com
  13.  
  14. > Date: 19 Aug 92 16:05 GMT
  15. > From: KLEIMAN@AppleLink.Apple.COM (Kleiman, Ruben)
  16. > Subject: Re2: LISP - Oracle
  17. > To: CFRY@MIT.EDU,
  18. >         INFO.MCL$@AppleLink.Apple.COM (Macintosh Common Lisp User's Group)
  19. > Cc: KGRANT@US.ORACLE.COM, HARTLEY.AK@AppleLink.Apple.COM (Hartley, Alice)
  20. > 
  21. >  
  22. > CFRY> At the conference, there was a movement to make some CL
  23. > CFRY> industry-wide defact standards for: CLIM, Foreign Function Interface,
  24. > CFRY> and SQL interface. The plan was not to go through the whole ansi
  25. > CFRY> process at this time, but simply have a generally agreed
  26. > CFRY> upon spec by the major Lisp vendors that would permit
  27. > CFRY> users to port their code.
  28. >  
  29. > Chris,
  30. >  
  31. > I agree that a standard API for SQL (and FF access) is essential. However, I
  32. > would NOT like to see it linked with CLIM (not because of any opinions I may
  33. > have about it, but simply because CLIM's objectives are orthogonal, I think, to
  34. > database and foreign function access).
  35. I agree completely. CLIM and SQL should be totally orthogonal. Sorry if I implied 
  36. otherwise. On the ohter hand, it may be easier to build a portable SQL interface on top of 
  37. a portable FFI so seems to me that that makes sense but is by no means necessary.  
  38. > Also, I would like a database-oriented API to also consider transactional
  39. > (e.g., CICS, IMS) and object-oriented (e.g., ITASCA) database management
  40. > systems as well as SQL. Since many of the issues are similar in all of these
  41. > (e.g., security, transaction bracketing), it would at least be possible to
  42. > design an SQL-specific version of the API that is architecturally extensible to
  43. > the others.
  44. This is a bigger project, though it is one that I'm also quite interested in.
  45. In fact, the architecture for the program I'm working on is designed to be able
  46. to use objects stored on several different kinds of databases [SQL, OO, 
  47. an-invented-here-flat-file] without caring about which (most of the time).
  48. Certainly to the extent that an SQL DB interface can be generalized, it should be.
  49.  
  50. shafto@aristotle.ils.nwu.edu (Eric Shafto) is interested in this issue. I know of
  51. 1 other MCLer in the Boston area [not on the net] too. Combined with Harlequin
  52. [soon to be networked, their new US office is in New Hamshire] maybe we've got
  53. critical mass!?!
  54.