Going from webscripting to server-client software.

Stephen shriek at gmx.co.uk
Fri Jul 27 07:55:59 CEST 2001

> > intranet and it was really easy. But it was possible for one of the
> > staff to be looking at a resource (eg. a squash court) and not
> > be aware of a booking made by another member of staff in real time,
> > which could lead to double-bookings if telephone bookings are made. 
> > They do not like to hit refresh in order to see the most up to date
> > status of a particular resource. They want software more like 
> > Windows-applications. 
> Have you considered a small applet that displays the status of the
> currently viewed resource?  This might be created in Jython and
> automatically update from the server at a specific interval.

Yes, I did consider it, and am still considering it for sales staff who
only have read ability (see below for reasons). This is also why I didn't
consider Worldpilot as somebody else kindly suggested.

It would still result in the same problem with changes by one client 
being updated on all other clients in real time.  Do the applets keep
polling for changes ?  If Sue books the slot 2-3pm on squash court 1,
I'd like the block representing it to turn red on all other clients
in real time, without staff intervention. (They've got other jobs to do, 
as well as taking phone bookings etc)

> > How should I keep all of the client applications in synchronization
> > with each other?  When each client app is opened, it gets all the 
> > bookings for the day from the server.
> Are they able to edit the bookings once the data has been downloaded? 
> i.e., do they get the data in "read only" mode then click on a button
> or link to edit the data?  If so you might create a lock file, or
> similar item, on the server when someone clicks on the edit button or
> link.
> If anyone after that clicks on the edit button it could check for the
> existance of the lock file.  If the file is present they might see the
> current information and who has it locked but not be able to edit the
> information.

Yes, they can edit the data (insert new entries or move/change existing 
bookings). Using a lock creates the problem if they then kill the web
browser. Yes, the lock could be timed out after say 3 mins (it can take 
them that long to insert contact data etc) but that still could result
in a lost booking if another person were trying to book the same time
during those 3 minutes. 

Really, I'm trying to get away from a stateless, non-updated-in-realtime
web app to more of a client app, something that might have been created
in Delphi or VB in the past.  Especially since it might give us the 
flexibility to integrate with other applications, such as the membership
system and email apps. (The web just doesn't lend itself to building 
look-ahead auto-complete fields for names, emails etc).

Thank you for taking the time to help.


More information about the Python-list mailing list