JJ,

===============================================
I agree that business needs to be a big priority. After all, it has
really
been business that has driven the successful open source projects (well
most
of them).
===============================================

No argument.


===============================================
But I still maintain that the web is the GUI for business applications. 
===============================================

Argument :)  Well, I at least want to define what you mean by a business
application.  I am quite skeptical that web browsers are going to
replace fat clients over night.  What about embedded systems and
servers?  I will admit that a service that is (securely) configured via
a web interface has some appeal, but it is not for every device.

Another cash cow of mine might be described as an etch-a-sketch with a
type A personality.  That thing serving web pages to itself to avoid a
direct GUI is hard to envision.



===============================================
For
one thing, how do you deploy a native squeak app anyway? The way Dolphin
does it is by stripping out all the un-needed parts, packaging the
"non-app
related but needed" things into DLL's and then turning it into an exe.
But
as far as I know squeak doesn't have a stripper like that, and I would
expect it to be years away.
===============================================

Agreed.  What's the problem? :)  Humor aside, one would simply lock down
the image, perhaps dumping unneeded packages/change sets.  You could
also go the other way: synthesize the image, starting with a kernel and
running a script or a tool that loads the required stuff, and saves the
imaged (locked down) under a new name.

Note that I have no idea how to do that (other than by extrapolating
from the lockdown package on SM), but it seems reasonable.  Dolphin
would have a significant edge on deployed size (as well as the ability
to deploy in-proc COM servers), but AFAIK, there is nothing to stop us
from giving users an icon that launches an "exe" created with Squeak -
just create a shortcut that names the VM and the image.  With current
network speeds, I am much more worried about the feel of the resulting
Squeak UI than I am about packaging, distributing and installing it.



===============================================
But you can have a seaside app up and doing work for your business in
literally minutes, depending on what you want to do. As a matter of
fact, I
would be willing to bet that with the persistancy work Keith has been
doing,
you can go from nothing at all to a functioning Content management
system in
squeak faster then any other system out there.

Not to mention the fact that in my company (and I would expect this of
any
company of size) it is a big deal to roll a desktop application out.
Every
release has to go through rigerous testing, the Q&A group, possibly an
after
hours deployment, etc. etc. But a new website I can just put up. And
then
*everyone* has it. That is a pretty big advantage.
===============================================

Should not your web app go through the same level of testing?  All a web
site does is simply distribution - the design/coding/debugging/testing
is just as hard as a desktop app.  If the web app deals with money,
lives, confidential info, etc., then it should be _very_ carefully
tested, all the more so because any nut with a web browser has a
ready-made client on his wireless PDA.  I am not advocating "security by
obscurity", but a web server is very quickly discovered, and even more
easily challenged  =:0  Correctness is also a concern.  Could a quick
change suddenly start corrupting old data?  Is the new data being
written readable and correct, etc.?

Turning it around, I just "put up" new desktop apps.  Of course there is
a lot of automated testing and some sanity checking of the critical
pieces as I go.  I wouldn't dare try it in any language (at least that I
have seen so far) except Smalltalk.  Again, I worry more about the
security of the web components (which exist in the system as a whole)
than I do about the desktop apps.

Bill




Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: bills at anest4.anest.ufl.edu
Tel: (352) 846-1285
FAX: (352) 392-7029