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@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?
squeak-dev@lists.squeakfoundation.org