Andreas wrote:
 
Andreas Raab wrote:

> Why don't we just take
> out stuff that is not needed to actually run squeak in some sort of
> plugins?! The only thing which would be needed is a well-defined
> interface
> to access, register and unregister from the VM. Than we could put a
> whole
> lot of stuff in separate classes (such as BitBlt) and keep the actual
> interpreter small.
>
> Even more, we could build customized VMs for certain application
> domains
> which might not include networking, sound, or even file support (if
> its
> running a bare chip system). Also, adding new stuff would be probably
> much
> easier - you would not have to modify the Interpreter but could just
> create a new plugin which can be translated into C code.

I like this approach. If we could seperate most of the machine specific
I/O out of the Interpreter and place the support into "plug-ins", this
could satisfy most of the concerns that have been voiced on the list
lately. Shrinking Squeak for hand held devices seems diametrically
opposed to multi-megabyte devolopment environments. A configurable VM
would seem to solve this problem nicely.

A facility for message passing from the VM should also be formalized.
Here is an example: I am currently working on native widgets for the
Mac. The Mac VM event dispatching loop is sprinkled throughout the VM.
When a window update event is received,  the VM passes the event to  C
support code. What I would like to do is pass a message from the VM to
an window object in Squeak saying "this window needs updating".

Of course, a pluggable event handler in the VM would mean that a person
on a big machine could write their event handler in Smalltalk, while a
person writing for a hand held device could keep all of their event
support code in C.

This of course brings up another question -- how do we handle image
startup / configuration ?

Jim Benson