[Zope-dev] Using Zope in a client-server system

[Tres Seaver]

Itai Tavor <itavor@bigpond.net.au> wrote:

> 
> Michel Pelletier wrote:
> 
> >  Itai Tavor wrote:
> <snip>
> >
> >>  There are a couple of features that I am not sure how to implement though:
> >>
> >>  - I need to display constantly-updating information on the
> >>  workstations. I could do this by reloading the window every second,
> >>  but that seems ugly - I'd like to only update certain fields, which I
> >>  can do using layers and JavaScript, but I need to get the updated
> >>  data from the server. I guess that can be done with Java, but I'd
> >>  like to keep the system simple - a browser with HTML and JavaScript
> >>  only on the client side, DTML, Zope with Python Methods, and External
> >>  Methods, and an SQL database on the server, no Java or any other
> >>  complications.
> >
> >  Ah, well, you see you've hit one of the disadvantages of using a
> >  stateless protocol like HTTP to solve your problem.  There is no good
> >  general purpose solution that I know of to address this issue.
> 
> HTTP not being bi-directional is a bigger problem than it being
> stateless... I planned to use a session product that will identify
> each workstation and keep a record of exactly what is happening on
> it. But the biggest problem is that the browser / web server setup is
> client event driven.
> 
> >>  - I also need to push data to the workstations - based on events
> >>  detected at the server, I need to bring up a message on a
> >>  workstation, and remove it in response to another event. I really
> >>  don't want to refresh a frame every second for this, and I also would
> >>  hate to have to write a Java applet to do it.
> >
> >  This is the identical problem to the one above.
> >
> >>  Any comments or suggestions regarding the above problems, the choice
> >>  of Zope for this project, or the project in general would be
> >>  appreciated.
> >
> >  If you want to go far enough, you can try and use XML-RPC (also,
> >  stateless, but not client-bound to a certain model) and something like
> >  wxPython to build your own GUI that can at least mantain some sort of
> >  persistent or bi-directional communication between your clients and
> >  servers.  But this is a big task.
> 
> Programming my own GUI is already farther than I'd like to go... and
> if I do, would it still be a good idea to use Zope on the server
> side? If I use Zope, wouldn't I still have to use HTTP? How otherwise
> can I get the client to communicate with the server? (Complete
> ignorance of XML-RPC implied here.)
> 
> >  I think if you maybe rethink your problem you can compromise on
> >  something that does not require the server pushing data to the client.
> 
> Yeah, without actually failing to deliver any of the features the
> client is expecting... the only way I can think of is simply to
> reload certain frames every second... seems like a very ugly solution.
> 
> I need to quote on time and cost for this project, and to do that I
> have to figure out the tools I'd be using. I'm sure a Zope/web
> browser solution will be the quickest, but if I go that way and get
> stuck, I won't be in a very enviable position. I'm sure that most
> programmers would immediately start coding Java or VB at this
> point... am I making a mistake trying to apply Zope to a task it's
> not good for?

By default, browsers aren't servers:  they don't know from
bind()/listen()/accept(), which is what push technology requires (unless you
have a long-running, bi-directional connection between browser and server, which
HTTP doesn't allow).  Polling is the only "native" technique for refresh, and
suffers from _horrible_ scalability problems.

Options in order of simplicity:

 1. Pull instead of push (ick!)

 2. As Hung Jung suggests, build the "push model" stuff separately from the
    browser, using Python or Java to implement HTTP (and perhaps XML-RPC?)
    Integration with the browser is difficult:  clients will have to have
    some mechanism for registering their mini-server with your server;
    if you want the broser's display to update when the push event comes in,
    you may be stuck.

 3. Code a lightweight socket server applet in Java, persuade everyone in
    the world to trust you to run it in their "applet sandbox", and then
    "register" it with your server.

 4. Write a CORBA callback object in Java, and register it with your server;
    the server then pushes events to your object (scalability is again an
    issue, as the server blocks for each client being pushed).  Note that
    adding CORBA into Zope is a non-trivial exercise, for the moment at least;
    see my "notes":http://www.zope.org/Members/tseaver/CosNaming on the
    issues.

 5. Write a CORBA event-channel applet (CosEventPushConsumer) in Java, set
    up a CosEvent/CosNotification channel, subscribe the applet to it, and
    push events to the channel from your server (decouples your server from
    event-delivery hassles/blockage, scales MUCH better than direct callbacks).


-- 
=========================================================
Tres Seaver         tseaver@palladion.com    713-523-6582
Palladion Software  http://www.palladion.com