> the major question is... Given that there is all this
> effort, and that we should taken advantage of it, how
> would you suggest to do so?

[Parenthetically, for those who don't know, Eric is the author of Pocket
Smalltalk.]

Seems to me that there are a number of ways to leverage Java:

  1. If Frost or other Java-on-Squeak-VM were working:
	(a) Java code could be integrated as/if needed.
      (b) more Java programmers would get involved with Squeak.
  2. Full and easy SOAP/XML/et al support in Squeak for using/publishing web
services.
  3. Get J3 into the mainstream build, with support for PPC, x86 and ARM.

Ok, the last point is really aimed at getting Squeak performance up so that
#1 performs.  If I had to prioritize them for best impact, I'd say 2, 3, 1
(my own preference would be 1, 3, 2, but that's my personal bias).

I'd also go with Bijan Parsia's comment about re-implementing.  If you look
at Java today, the major focus of development is on enabling web services:
portal tools, database tools, development tools.  Pervasive end-to-end
computing is the goal, and there is work on all areas, but the primary focus
has been on the server side in recent years.

Although Squeak has some stuff in those areas, they aren't Squeak's strong
suit.  Thus they represent opportunities for re-implementation.  Plus, there
is the question security: how do we build firewalls around "foreign"
objects?

This brings us back to item #1.  In the portal technologies, one of the
things that appears to be coming is that my portal could download a portlet
from another company's server.  The provided portlet would then run on my
server, providing data from their's.  So given this notion of "Java agents"
(if you will), it would be helpful to be able to support them.

> As I understand [SWT], [it's] more or less a re-implementation of the
> VisualAge/Smalltalk Common Widgets, which does exactly the same thing
> in Smalltalk, and has for many years.

Eric's point, AIUI, was that unlike Squeak, which does everything on a
framebuffer, SWT uses the native GUI widget set.  The goal was the thinnest
layer that provided for common functionality, but platform-specific L&F.

See:
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-swt-home/ma
in.html
     http://www.eclipse.org/articles/Article-SWT-Design-1/SWT-Design-1.html
     http://www.eclipse.org/articles/index.html (SWT section)

Ask anyone who has used Forte and Eclipse about the difference in L&F and UI
responsiveness.  Plus, SWT now runs on Pocket PC, where it is quick zippy.
Unlike Morphic (floating point is a killer on StrongARM).

	--- Noel