I can imagine a system where the display for another hydra instance appears
like a small icon (akin to a morphic sub project, or even a croquet
portal)...jump into it and the bits on the display are being painted by the
other hydra instance.  You are now immersed in this other object space and
able to freely work with all the tools, etc.  This seems a much easier path
than trying to shuffle a bunch of objects between images and build remote
enabled tools.
- Stephen

On Fri, Feb 22, 2008 at 12:43 PM, Andreas Raab <andreas.raab at gmx.de> wrote:

> Igor Stasenko wrote:
> > Well, there is people who wish to see such capabilities, and if Spoon
> > features orthogonal to your approach, then why not include them?
>
> Because there is cost associated with it. Probably some runtime cost
> (which I haven't measured) but definitely cost in terms of added
> complexity in the VM.
>
> > In this case both camps will feel suited with new VM and can use it in
> > one way or another.
>
> My problem with this is that I cannot see any situation in which someone
> would really want to rely on that mechanism. It seems to me that the
> approach is (as you said in an earlier email) a way to create smaller
> images "without much effort". I'm interested in the *hard* way of doing
> this (i.e., by going in and refactoring and removing things manually)
> because I think this is the only way in which it can be done in practice.
>
> But be that as it may - the real question is this: Let's assume we have
> a tiny kernel image that is about 100k in size and that we can build up
> from. What good is the mechanism at this point? It seems to me that it
> is only useful to get to a small image but once this is achieved it's
> basically obsolete. And I'm definitely not in favor to modify the VM for
> something that will only have a very short window of usefulness.
>
> Cheers,
>    - Andreas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080222/c1c92e48/attachment.htm