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
|