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.


Dan,

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...)

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".

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.

Mike

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).