Everything is a distributed object

Howard Stearns hstearns at wisc.edu
Sun Oct 8 18:55:18 UTC 2006


There may be more to the problem, but what is described by Martin  
does not really require a general distributed object solution --  
which is fortunate.
The situation described is the usual domain of "rich client"  
architectures (pun often intended).

http://www.laszlosystems.com/
http://www.curl.com/
http://en.wikipedia.org/wiki/AJAX

[Disclosure: I was Technology Strategist at Curl and have many  
friends there and at Laszlo. There are other players in this field,  
too.]

On Oct 8, 2006, at 4:28 AM, Martin Drautzburg wrote:

> 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.
>
>
>
>
>
>
>
>
>
>




More information about the Squeak-dev mailing list