On Saturday, 7. October 2006 21:34, Michael Latta wrote:
> The one thing
> that the web services people got right is that you need to know when you
> are talking to a remote object and handle that differently than those in
> memory. Any other approach produces toys or failures.

Thats bad news. maybe I shoud explain why I want to know this. This issue is 
not strictly sqeuak related, it is just that a lot of smart people are on 
this list.

We are currently in the situation where we need to support a larger user base 
of apx. 500 users. Our current application includes a fat client, a J2EE 
business logic layer and a databse backend.  There are two main problems:

(1) The client is too slow over a slow network (this is mostly our fault)
(2) We need 500+ client installations and we need to repeat those 500+ 
installations with every upgrade of the client.

Of course (2) can be attacked with clever remote installation mechanisms like 
java web start, and this is certainly an option, but I thought there might be 
a more elegant solution.

This idea is to install a "browser" on the users machine just once, a browser 
that can display about every possible application. With this approach I can 
see two obvious solutions:

(2a) Use a web browser and develop a web app. This has the drawback, that the 
possibilities you have to design your GUI are very limited and that you have 
to program things in strange ways. 

(2b) Use an X11 server on the user's machine. This eliminates the drawbacks of 
(2a), but is expensive memory-wise. With every session the application has to 
be started anew on the central machine. An experiment with a wxPython app 
showed that this can easily be 30MB of (non-shared) memory which adds up to 
15GB for 500 users. Another problem with this approach is that window 
repaints are sometimes visible, which looks irritating to most users, even if 
the overall time it takes is quite small. The good thing here is (contrary to 
what you said): you do not have to know when you are talking to a remote 
object.

Then I was looking at "pyrc" a remote python thingy, that promises transparent 
access to remote objects. So I thought: cool, I let the server (the user's 
machine) import the wxwidgets toolkit and I remote-control it from the 
client. So the client will not even have to import the wx toolkit (reducing 
memory footprint) and the client programmer can write the client code as 
usual.

But alas, an ubiquitous pattern in GUI development is subclassing widget 
classes from the toolkit. This does NOT work with pyrc. 

Generally speaking I would need a protocol (other than http) that intercepts 

- somewhere below the X11 level and communicates higher level objects (not 
just rectangles and events-in-a-rectangle), to eliminat the drawbacks of (2b)

- and above the database protocol (SQLNET) because that will result in a fat 
client again.