It's very exciting to see someone looking at C integration with Squeak. 
It would be great if talking to a Squeak VM was as easy as talking to an
object in Smalltalk.  It would mean a lot more people use Squeak over
time, and it would mean that  a lot more libraries are at the fingertips
of Squeak fans.  It would mean that writing tiny Squeak scripts becomes
easier.  It would mean people can experiment with Squeak by writing just
one module of a large system in Squeak instead of betting the whole
program on whether Squeak turns out to work well for them.  There are
tons of reasons that being able to talk to the outside world would be a
very good thing, but since they are all long-term advantages, no one
gets motivated to work on them.

But I do think it's important, and my working assumptions have been:

	1. If you want to talk to the software world, speak C.  It's the lingua
posixa and almost everything can speak it in some fashion.

	2. Speaking C without an accent means you have to support callbacks
and using the Squeak VM as a library.

	3. Allowing callbacks means that the interpreter must be reentrant and
that the VM is implemented with a call stack that alternates back and
forth between Squeak and C.

All of this reasoning, by the way, is closely paralleled by TCL's
architecture.  Ousterhout really did a great job with TCL<->C
integration.

Given this background, enter Daniel, the hero.  If I understand
correctly, Daniel, you have a new strategy slightly different
from the above reasoning.    If I understand correctly, the DBus
strategy might be an alternative that is easier than #3.  Further, it
seems plausible that DBus will become a widely used  "language" of its
own -- perhaps even *the* lingua posixa of 2010 -- thus meaning #1 on
the list above is unnecessary.

I wish I knew enough about DBus to critique that strategy in detail, but
you are the first person I've seen pushing DBus.   So beyond
posting a few questions to think about, I'll chearlead and then duck
out.

Some questions:

- How hard is it to bind an *arbitrary* C program to DBus?  If it's
easy, then that means we can talk to arbitrary C libraries even when
they don't already have DBus support.  (It also means that DBus will be
supported more widely, because people can say "why not" and offer DBus
bindings.)

- You mention some impressive high-level examples--TeapotMorphs
and TFrames.  How about basic stuff like arithmetic?  That is, how hard
would it be to write in C the following:

	obj = executeSmalltalkCode("Compile evaluate: '5 factorial'");

How complicated is executeSmalltalkCode()?  I ask about this example
because I am wondering about what the exact overheads are of going via
DBus.  Those overheads can easily disappear into the noise if you are
doing a more complicated project.


But that's all the serious questions I got.  I hope that the project
goes well and that it achieves the ultimate goal of being able to easily
talk with other languages.  Even if it doesn't get there, it sounds like
having a handy DBus interface is very useful by itself.  Please update
the list with any further work you do on it -- this is useful stuff!


-Lex