You can certainly design a protocol between your server and client that is
better than raw X11 or raw SQLNet.  As you point out that will require you
deploy an application to each client.  Something like web start is a good
way to manage that deployment.

As you pointed out the use of X11 to a remote machine is not satisfactory,
while locally it is fine.  This is one quality of service difference between
local and remote access you can not ignore.  At a fine-grained programming
level things get far worse then flicker very quickly.  X11 is relatively
efficient and was originally designed to function in that situation.  This
is not to say remote objects do not work, just that you need to design your
application so you know when you are incurring the delays and potential
failures of a remote connection.

Michael


> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org [mailto:squeak-dev-
> bounces at lists.squeakfoundation.org] On Behalf Of Martin Drautzburg
> Sent: Sunday, October 08, 2006 2:29 AM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: Everything is a distributed object
> 
> 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.
> 
> 
> 
> 
> 
> 
> 
>