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