External vs. internal facilities

Interfaces to external facilities need not be in conflict with  
providing comparable facilities in Squeak itself.  For example, I  
don't think there is a problem with interfacing to platform-provided  
font-renderers, as long as the interface is compatible with the  
Squeak-internal one.  In fact, I am almost sure that Squeak-Central  
would welcome such a move.  The external interfaces can serve as  
reference implementations and kick-start mechanisms, allowing a  
Squeak implementation to be built by gradually replacing the external  
mechanisms.

Interfaces need not be identical, all that's needed is a common  
base-level that provides plug-compatibility.  Further features can  
then be layered on top of that.



Simple module support

The problem with module support at this point is probably not a lack  
of good ideas (seen plenty) and sensible requirements (ditto), but  
more an incremental approach to those goals.

My suggestion would be to start with something minimal, something  
that (a) can be implemented without changing existing semantics (b)  
is a step in the right direction and (c) isn't too difficult.

One thing that came to my mind is a very, very simple implementation  
of a modularization mechanism, the ability to integrate Squeak  
classes/methods (no more!) into an image without actually copying the  
stuff into the image (read-only, shared).

This could be accomplished by having cover class-objects that refer  
back to a read-only part not part of the image and also to a normal  
writable part (possibly empty) that is part of the image.  Any  
modifications made go to the writable part, which overrides the  
read-only part.  The pointer to the referenced read-only part would  
probably have to be hidden from the garbage collector.

The system behaves exactly as it does now, changes are made to the  
local image and override what is in the loaded modules, which are  
themselves not modified.  Once modifications to a module are well  
established, a new module with those changes incorporated can be  
generated.

The semantics of such a system would be similar to remote messaging  
to a separate image, but with a fast local messaging implementation  
and local override capability.


SMS extensions

The similarity to remote messaging can be used to make a remote  
interface simply a special case of a module where the code is not  
locally available.  Native interfaces could also use the 'module'  
mechanism.  In each case, the module could provide a custom messager  
that communicates the message via IPC or uses C-style argument  
passing with conversions.