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

[Itai Tavor]

Tres Seaver wrote:

>Itai Tavor wrote:
>  >
>  > Tres Seaver wrote:
>  > >
>  > > 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!)
>  >
>  > My sentiments exactly.
>  >
>  > >   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.
>  >
>  > Right. Mixing two GUI's - a browser for most of the interface and a
>  > separate app for pushed data - would be real ugly. So I either have
>  > to work inside the browser, as in option 3 below, or code my own GUI.
>  >
>  > Registering the mini-servers would not be a problem. This project
>  > will be running on a small number of workstations, all located in one
>  > location. It's not designed for public or wide-area use and won't
>  > even be connected to the internet.
>
>If you control the deployment platform, and the pipe between client 
>and server,
>then some of my tradeoffs don't apply, as you note:  trusted applets are
>reasonable, for instance, and polling is not nearly as terrible a 
>strategy over
>a fast network with a small number of clients.

Yeah... which brings me to making the choice to stick to the original 
plan of putting all the client UI inside a browser.

>  > < snip >

>  > - Would it still be a good idea to use Zope for the server, or should
>  > I code the server as well (a full Java solution comes to mind using
>  > COBRA for two-way communication). How would I handle push in Zope?
>  > Assuming I code a push client that speaks XML-RPC, how do I get Zope
>  > to send data outside the context of an http transaction? Actually,
>  > this same question is relevant for the solution of using a Java
>  > applet within the browser.
>
>You might look at Loren Stafford's recently-announced ZScheduler 
>product:  Loren
>is working on a way to have "internally-generated" events fire inside Zope.

I've been forced away from Zope by other work, the current status of 
ZScheduler is one thing I need to catch up on.

>  > - Two good candidates for writing the GUI in are Java and wxPython.
>  > Using wxPython would have the advantage of keeping everything in
>  > Python. On the other hand, there's an XML-RPC server for Java, but
>  > not for Python - I guess I would use HTTP if I use wxPython. Can
>  > anyone suggest pros/cons for these solutions?
>
>I think I missed something here:  Python *does* have an XML-RPC server
>implementation (xmlrpclib.py), which is how Zope can do XML-RPC.

I was thinking that for real two-way communication, the workstations 
will also have to be XML-RPC servers, and while I know that Zope can 
do that I have no idea how hard it would be to get xmlrpclib working 
outside Zope. But that's not really an issue if I use polling.

>  > I have one other question related to the use of Zope in this project:
>  > The server has to monitor a serial line and respond to received data
>  > by pushing messages to the clients. What would be the best way to
>  > achieve this? An external python process reading the serial line and
>  > calling ZPublisher.Client to triger a DTML method that will do the
>  > rest of the work?
>
>Right, but ot necessarily a DTML Method.  The ZClient request might, for
>example, trigger a method of a Python product instance, which could 
>enqueue the
>event for processing by a notification thread, for instance.

Ok. My main concern was how to get the external event into Zope, once 
I achieved that it will probably be dealt with using a product or a 
Python method.

>  > P.S. I know this is getting way off topic for the Zope group. I
>  > really appreciate all of you contributing your experience.
>
>I don't think this is off-topic at all -- we are pushing the *normal* Zope
>envelope a bit, but I think Zope is up to the challenge.

Glad to be pushing my little corner of the envelope :)

--
Itai Tavor                      -- "Je sautille, donc je suis."    --
itavor@vic.bigpond.net.au       --               - Kermit the Frog --
-- "What he needs now is understanding... and a confederate victory" --
-- Dr. Jacobi, Twin Peaks         --