Hi Andreas--

 > ...I was *amazed* how usable it already is in terms of speed (10-20%
 > slowdown) as well as productivity.

      Great!

 > Since the basic development process is in place (load alternative
 > images, send commands, save the result) I was thinking about the next
 > steps and it occurred to me that having a set of tools that can
 > operate on another image would be tremendously useful. Not only for
 > development inside Hydra but also for some of the people out there
 > trying to create smaller images.
 >
 > With a set of HydraTools you should be able to for example, rip out
 > *all* of the UIs and tools that exist in an image, fix up the result
 > and be able to try loading the UI framework from first principles.

      I've done that with Spoon, with separate VMs communicating over a 
proxy system that uses sockets. It would be interesting to extend the 
proxy system to use Hydra's channels (some form of inter-thread 
communication I assume, I haven't looked at the Hydra implementation yet).

 > So my question is basically this: Is there a tool set (browser,
 > senders, implementors, maybe debugger) that has "enough" of an
 > abstraction about its model that it would be easy to fit in the Hydra
 > channel protocol to make them work?

      My approach with Spoon was to just have a completely transparent 
proxy system, so that all the normal tools work without special support. 
I've had all the tools you mention working remotely for a few years now. 
I did do some magic to support debugging processes which have a 
combination of local and remote contexts, but it was surprisingly little.

      Anyway, the proxy system isn't especially tied to sockets or any 
particular transport, so I think this is doable.


      thanks,

-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]