The idea isn't obsolete at all.  Look at many of the major applications from 
Squeak:  all slimmed down versions of Squeak and in some cases you wouldn't 
even realize it was Squeak if you didn't know what to look for.

And I don't understand all the talk about it being so hard to do.  Dolphin 
does it and it works wonderfully afaik.

The bottom line is, Linux and (I think) Mac are a market that is open for 
someone who can build GUI applications very quickly.  Who ever can make the 
nicest apps the fastest will win these markets.  But if you come thumping 
the blue book saying "stand alone apps are obsolete, just use the image" 
then don't even waste your time.

If Alan Kay's new project works out maybe this will change some-what, but 
for the existing OS'es, deployed applications will be stand alone if they 
want any acceptance.


>From: "Paul D. Fernhout" <pdfernhout at kurtz-fernhout.com>
>Reply-To: The general-purpose Squeak developers 
>list<squeak-dev at lists.squeakfoundation.org>
>To: The general-purpose Squeak developers 
>list<squeak-dev at lists.squeakfoundation.org>
>Subject: Re: "Inteligent" Shrink?
>Date: Mon, 26 Feb 2007 14:26:07 -0500
>
>Having packaged Smalltalk apps in the past, I agree with this, and would 
>remind people that the whole "shrink" metaphor arose out of commercial 
>goals -- that is, in order to deploy a Smalltalk "application" built on a 
>proprietary platform you needed to remove the compiler and development 
>tools to comply with a vendor's license. Since Squeak does not have such 
>licensing issues for deployment, the whole "shrink" idea is obsolete IMHO.
>
>Why take a perfectly working application and start potentially introducing 
>all sorts of random errors into it at the last minute just to save a bit of 
>storage space and network bandwidth (especially these days)? And if storage 
>space and bandwidth does matter in your situation even now, then building 
>up from a small base (including a text based one) is a much more reliable 
>way to produce quality deployable applications.
>
>--Paul Fernhout
>
>Ralph Johnson wrote:
>>Given the current state of things, it is important to have tools for
>>shrinking.  I've been programming in Smalltalk for 20 years, and I've
>>seen lots of different tools.  My conclusion is that the "shrinking"
>>model is flawed, and it would be better to focus on making Squeak
>>"growable".
>>
>>If you develop in an image and have no way of getting all your code
>>out of an image then you are in trouble.  Images are fragile.  You
>>can't merge images.  If you want to give your code to someone else, or
>>if they want to give it to you, one of you has to move code out of the
>>image and give it to someone else.  So, it is important to keep your
>>code in files, whether as .cs files or in Monticello.
>>
>>If your code is in files, there is no argument against growing an
>>image.  Sure, you will develop in a huge "dev" image.  But it is built
>>out of components and many of those components are not used by your
>>application.  It is a lot easier to shrink a build script than to
>>shrink an image.  You could have a tool that automatically shrinks
>>your build script by deleting packages one by one and seeing if your
>>application still runs all its tests.
>>
>>Shrinking an image is hard work and not for the faint of heart.  I
>>always tell my students to build their application first and worry
>>about shrinking at the end.  That is because they will be a lot better
>>at Smalltalk at the end of the project than at the beginning, and so
>>they will be better able to learn to shrink their image.
>

_________________________________________________________________
With tax season right around the corner, make sure to follow these few 
simple tips. 
http://articles.moneycentral.msn.com/Taxes/PreparationTips/PreparationTips.aspx?icid=HMFebtagline