>Dan Ingalls <DanI at wdi.disney.com> wrote:
>> I believe THEN that we could replace nearly every class in the image with a phase-1 snapshot stub.  This would be a lot of fun.  All the kernel classes would just pop right back in while you were doing it, because they are being used all the time.  You could start up some application to bring back what it needs as well.  Then you would enumerate the remaining phase-1 stubs, forcing them to file as phase-2 stubs, and save the image.  At that point you would have a small image containing exactly the classes needed to run the application, with all the rest in files linked to the image like a cloud of DLLs.  A user who only ran the application should never see a fault.  But if that image tried to do something new that required another class, it would pull it in as needed.  This could allow reasonable post-delivery maintenance of compact applications.

Mike -

>I am intrigued by the general idea, but curious what this would entail.  (I am also not sure which problem this is a solution to...)

I could write about this, but I'd rather just send you the source code -- it's half done already!

Ted Kaehler and I are doing this together.  I'm writing the (simpler) primitive to extract an image segment.  Ted is writing the more complex one to load an image segment, and the further code for inter image externalization.  It turns out that this all parallels the existing fairly complex code for veryDeepCopy and saveOnDisk.  It may be much simpler and it will be much faster.

>As I understand, the idea is to replace the current monolithic image by a small primary image + a large number of small files containing binary phase-2 classes.  You could then replace one of those files to do "post-delivery maintenance".

We're not proposing to depart from the monolithic image which, for the most part, we like.  We ARE proposing (and acting ;-) to make available a simple and general primitive that will let one experiment with segmenting the image in various ways, and with exporting morphic worlds and other such live content to, and importing them from, external media such as the web.

>Do all objects of a given class live together in one external file along with all the methods of the class, or are the objects (if any) in the primary image and only methods in the external files?
>
>I feel like I am missing something here.

We're hoping to pull this off in an entirely general manner:  For any object, it will produce an externalized segment containing that object and any object pointed to by it that is not also pointed to from elsewhere in the image.  The idea is that if you can successfully trap accesses to the root object then, by def nothing in the system can be aware whether the rest of the tree is there or not.

>p.s. One of the good things (!) about the present BIG IMAGE approach is that everything is well co-ordinated at a binary level.  I can save an image in a directory with other images, and when I come back to it 6 months later it will still work (as long as the interpreter is equivalent).

Nolo contendere.

	- Dan (and Ted)