Various models might work. For a project that must include special UI
code (and since we don't want to contaminate the explorer image), it
might come up with it's own GUI, with the explorer image still be able
to connect to it, debug it, so forth.

I'm still thinking what a good connection mechanism would be. Maybe
something relatively high level like Jabber. As long as you don't try to
push too many bits too often, performance wouldn't matter much, and it
might provide a nice model for connecting to images sometimes living,
sometimes not.

Daniel

Brent Vukmer <bvukmer at blackboard.com> wrote:
> Oops.  I presssed 'Send' too soon! What I *meant* to type was:
> 
> ** Loading Projects ** 
> 
> I'm excited about this because I think that idea of Projects in Squeak
> is very cool but the experience of unsuccessful-Project-loads is not so
> cool. As I imagine it, Project windows would be built in the Project
> Explorer image as follows: 
> 
> (1) Get the URL for the Project image spec
> (2) Get the URL for the living objects that will be copied into the new
> Project image
> (3) Get the URL for the to-be-created Project image
> (4) Retrieve the Project image spec from URL in(1)
> (5) Build the Project image to spec, accessible from URL in(3) 
> (6) Import the living objects from URL in (2) into the Project image
> (7) Create a ProjectWorldMorph in the Project Explorer image
> 
> Steps (1) through (6) would be cool because the work of building a
> Project is separated out into nice clear simple steps. Dependencies and
> in general Project metadata become much more accessible.  Also we could
> easily build Project-subscription tools with this mechanism. 
> 
> I'm still thinking about step (7).  Would the cloud of Project images
> always be headless?  I.e., would MVC/Morphic/SomeFutureUI always only be
> loaded into a Project Explorer image?