Hello Squeakers!

While looking at various native call-out packages and thinking about  
my Objective-C bridge, it occured to me that, using the new named
pluggable primitives, it should be possible to integrate these into a  
coherent 'bridge' package.

The basic idea is that all native calls are represented by messages  
sent to proxy objects within Squeak, just like distributed object
implementations.  For another dynamic language like Objective-C, the  
proxy holds the native pointer and a simple function can pass the
message to the Objective-C runtime after it's been intercepted and
reified using #doesNotUnderstand:.  Optimized versions using direct  
calls of named primitives are still possible but not necessary.

For procedural APIs, the proxy could represent the entire DLL/module  
in question, and the message names could be looked up as function
names (after removal of keyword syntax).

The 'thunking' subsystem for converting parameters between native
and Squeak representations should be pluggable.  One 'thunker' would  
do native C data-types, others could convert to the CORBA's IIOP,
XML, HTTP-ng or Squeak's image format.

The method for obtaining type-information also needs to be
pluggable.  It could come from parsing header files, dynamically
discovered typing info (Objective-C), CORBA repositories or whatever.

I imagine that this should make call-outs better integrated with
Squeak by making the interface much smaller and making it easier to  
plug-in Squeak code for native code and vice versa.  There might also  
be benefits in reusing this code for remote-object support.

Does this sound reasonable?  Would the various native API
implementors want to pitch in to make this happen?  Would this make  
native APIs more palatable to Squeak central?  Other suggestions?

Thanks for your feedback,

Marcel