home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / lisp / mcl / 1269 < prev    next >
Encoding:
Internet Message Format  |  1992-08-18  |  2.8 KB
  1. Path: sparky!uunet!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: LISP - Oracle
  5. Message-ID: <9208181906.AA10096@MIT.EDU>
  6. Date: 18 Aug 92 20:05:20 GMT
  7. Sender: info-mcl-request@cambridge.apple.com
  8. Lines: 43
  9. Approved: comp.lang.lisp.mcl@Cambridge.Apple.C0M
  10. Original-To: Bruce Lester <72110.1107@CompuServe.COM>
  11. Original-Cc: info-mcl@cambridge.apple.com, kgrant@us.oracle.com
  12.  
  13. > I need to generate SQL in MCL 2.0, send it to a remote Oracle database server,
  14. > and parse the result in MCL.  I would like MCL to have control of this entire 
  15. > transaction.
  16. > 
  17. > Has anyone attempted to communicate with Oracle using MCL?
  18. > 
  19. > Did anyone attend Cris Kobryn's "Interfacing Lisp to SQL Databases" tutorial 
  20. > at the "Second International Lisp Users and Vendors Conference"?
  21. I did. Cris Kobryn works at Harlequin. They make a bunch of add-on Common Lisp
  22. software products intended for multiple hardware platforms. 
  23. I don't think they've brought up their SQL interface on the Mac yet.
  24.  
  25. At the conference, there was a movement to make some CL industry-wide defacto standards 
  26. for:
  27. CLIM, Foreign Function Interface, and SQL interface. The plan was not to go through
  28. the whole ansi process at this time, but simply have a generally agreed upon spec by the
  29. major Lisp vendors that would permit users to port their code.
  30.  
  31. Franz, Lucid, Symbolics, and Harlequin seem to be moving in this direction.
  32. I'm not sure what Apple's plans are but please join me in encouraging
  33. Apple to cooperate here. In particular, a standard FFI to C code
  34. might go a long way toward writing useful portable utilities like an SQL
  35. interface.
  36.  
  37. For interfacing to particular products like Oracle, its likely that more than one
  38. MCL hacker could make use of such code. If the interface code were portable accross
  39. all CL implementations there might even be a market for such code. 
  40. Most likely scenerio is that the company selling the library supports a CL hacker
  41. for doing the interface [typically as part of a project the hacker is doing anyway]
  42. then takes over support and distribution of the interface software. I'd hope the
  43. goal of the company would not be primarily to make money selling the interface code
  44. itself, but rather in gaining more sales for their base product BECAUSE such an
  45. interface was available.
  46.  
  47. This message is being CC'd to Ken Grant who use to work at my lab [MIT Center for 
  48. Coordination Science] and is now at Oracle. One of my predicessors at CCS wrote a
  49. DAL <-> MCL1  interface whose intended use was with Oracle. Due to the cripling
  50. DAL limitation of only 255 bytes per record, the code isn't very useful. A more direct
  51. interface to Oracle would be.
  52.  
  53. We can save net work to the benefit of all with the right level of cooperation.
  54. You MCL hackers out there that need SQL interfaces, pipe up!
  55.  
  56.