Versioning and persistence

Patrick Logan
Wed, 21 May 97 09:07 PDT

>>>>> "Dwight" == Dwight Hughes <> writes:

    Dwight> Some possible complications to the LispOS "image" will be
    Dwight> Virtual Machines as first class objects and the
    Dwight> possibility of supporting "alien"
    Dwight> programs/languages/binaries.

I missed this in my previous response. This is good and necessary,
especially for Java.

One thing I like about the Java thing is that it is lifting the API up
off the CPU and placing it down on the wire. So instead of having to
link an application with all kinds of C libraries, the application
simply has to put the right bits on the wire. An easy way to put Java
bits on the wire seems to me will be to incorporate a JVM into the

One way to do this is to use Kaffe. Kaffe though seems to have a lot
of the "kruft" that shows up in a cup when it hasn't been washed in a

If a Lisp system has a good pre-emptive threading model, why not run
Java byte codes by translating them to Lisp, or compatible native/byte
code, etc.

Being able to run Java byte codes efficiently means you should have
relatively painless access to all the resources the Java beanies are
putting on the net: JDBC, CORBA, AWT, browsers as clients, etc. (Even
Gemstone! 8^(

BTW has a window system been discussed? I would recommend holding off
and using Tk and or AWT for the moment. Then the LispOS can be a
server to a browser or other client relatively cheaply. Implement CLIM
as a layer above these eventually. I think Tk would be a good starting
host for a CLIM, all things considered.

Patrick Logan       
Voice 503-533-3365            Fax   503-629-8556
Gemstone Systems, Inc