Hi Mike--

> Okay... I'm fiddling with Squat while my boss isn't around :-P.
> 
> Are Squat's modules "live"? That is, do they have their own threads and
> memory, so that messages from one module can travel to another module
> and be processed there? I know (or think I know) that Squat can import
> methods, and send remote messages to other running VM's.

	Right, any object in one system can send any message (with any objects
as parameters) to any object in another system (either on the same
hardware or different hardware over a network). Given that, modules are
normal live objects which do everything they need to do by sending
normal messages.

	A good example is how a module gets loaded from one system into
another. The target system, given the UUID of the module it wants (e.g.,
derived from some choice a human made), asks for it from another system
which has it already. The target system makes a new empty module, and
the two modules (the populated one in the source system and the new
empty one in the target system) negotiate what needs to be
installed/removed in the target (taking into account what the target
already has, etc.). It's all a live conversation, as opposed to using
files, where the author has to second-guess in advance what the target
system might be like. See Module>>synchronizeWith: in the Squat
snapshots.

> In terms of NameSpaces, are these (going to be) managed in Squat? Can
> you give a module access to the NameSpaces of (pointing in air) that
> module, that module and that module, and no other?

	So far modules are orthogonal to namespaces, and I like it that way.
Also notice that the module system never refers to classes by name, only
by object identity or (if necessary) UUID. With that, you can build
whatever class namespace mechanisms you like.

> Keep the good work up!

	Thanks!


-C

--
Craig Latta
improvisational musical informaticist
craig at netjam.org
www.netjam.org
[|] Proceed for Truth!