Going from webscripting to server-client software.
Stephen
World Wide Web either Python CGI or Zope. Now I am developing
some software where the client is no longer a web browser and I
find it's a much harder proposition.
The application is a booking system for a sports centre. There are
8 people who will use the software to check if a sports hall or
squash court is in use or reserved. I did this first with an
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.
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. If the user wishes to display
another day, it requests all bookings for that date. However, if
one client makes a booking or edits data, how should it update all
other client apps? Should it send the data back to the server and
then each client request any changes each and every second ? Or
should the clients communicate between themselves ? This latter idea
does not sound very scalable.
I know there's lots to learn here and would prefer to go read up
rather than trouble you so any helpful resources will see me on my way.
Should I be looking at SOAP/.Net or Visual Basic or Java/CORBA instead
or is Python up to it? What other caveats are there ?
I'm sure somebody must of created something like this already for
resource management.
Regards,
Stephen.
Emile van Sebille
Zope, it may be a good fit. Assuming, of course, that they have added
resource planning in the year and a half since I asked about it. Looking at
http://www.worldpilot.nl:8088/WorldpilotSite/Worldpilot/ suggests that it
may now be in there.
--
Emile van Sebille
em...@fenx.com
---------
"Stephen" <Shr...@gmx.co.uk> wrote in message
news:6572890e.01072...@posting.google.com...
Wayne
...
> 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.
> 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.
Wayne
Duncan Grisby
Stephen <Shr...@gmx.co.uk> wrote:
[...]
>I know there's lots to learn here and would prefer to go read up
>rather than trouble you so any helpful resources will see me on my way.
>Should I be looking at SOAP/.Net or Visual Basic or Java/CORBA instead
>or is Python up to it? What other caveats are there ?
This is the ideal kind of application for CORBA. You could model both
the booking server and each of your client applications as CORBA
objects. They would then easily communicate with each other so
everything is kept up-to-date.
Python is the easiest language in which to develop CORBA applications,
and there are a number of CORBA implementations available. This page
has a list of them:
http://www.faqts.com/knowledge_base/view.phtml/aid/4930
I won't recommend one. I wrote omniORBpy so I'm biased.
Cheers,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
Stephen
> > 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.
S.
Stephen
> >I know there's lots to learn here and would prefer to go read up
> >rather than trouble you so any helpful resources will see me on my way.
> >Should I be looking at SOAP/.Net or Visual Basic or Java/CORBA instead
> >or is Python up to it? What other caveats are there ?
>
> This is the ideal kind of application for CORBA. You could model both
> the booking server and each of your client applications as CORBA
> objects. They would then easily communicate with each other so
> everything is kept up-to-date.
>
> Python is the easiest language in which to develop CORBA applications,
> and there are a number of CORBA implementations available. This page
> has a list of them:
>
> http://www.faqts.com/knowledge_base/view.phtml/aid/4930
Thank you very much, Duncan. After looking around for a couple of days (hence
my late followup. sorry), it does seem like my options are
(a) CORBA
(b) SOAP
(c) XMLRPC
(d) Pyro
CORBA has always been intimidating. So much work just to do "hello world",
let along build a full app. Then again, I suppose it's less work than
trying to manage communications between all the distributed clients which
is what I understand CORBA takes care of for me. Interesting that you say
Python is the easiest language in which to develop CORBA apps because I
thought that that was Java's EJB selling point, that it takes care of
CORBA for you.
SOAP is interesting because of .Net
I was very excited by John Udell's article
http://www.byte.com/documents/s=804/byt20010712s0002/
where he mentions that in J2EE, the platform is the Java language but
.Net really does look language and maybe platform independent. Same
advantages of CORBA of course.
XMLRPC seems to have been superceded by SOAP and certainly doesn't
seem any faster. CORBA will be more appealing to me than SOAP or XMLRPC
from a speed and scalability point of view because I'd like to build my
booking application to be reused for other, larger companies and not just
my current client.
Pyro looks dead easy. Main problem being that if somebody else wants
to work with the system, to extend it etc, they have to use Python.
I try to provide clients with as many options as possible for future
development and not lock them into Python. Also, it's safer to go with
a standard thing like CORBA,XMLRPC,SOAP. However, well done to Irmen
for creating something so simple that works like CORBA.
> I won't recommend one. I wrote omniORBpy so I'm biased.
I've heard good things about that. Will check it out.
Most importantly, lots of documentation and win 2000 binaries (I like
to reduce the number of things that can go wrong) :)
Thanks again.
S.
Duncan Grisby
Stephen <shr...@gmx.co.uk> wrote:
[...]
>Thank you very much, Duncan. After looking around for a couple of days (hence
>my late followup. sorry), it does seem like my options are
>(a) CORBA
>(b) SOAP
>(c) XMLRPC
>(d) Pyro
You might want to add DOPY, which is along the same lines as Pyro:
http://www.users.cloud9.net/~proteus/dopy/welcome.html
I don't know anything about it, though.
>CORBA has always been intimidating. So much work just to do "hello world",
>let along build a full app.
People often say this, but it just isn't true, especially if you use
Python. "Hello world" doesn't make a lot of sense in a distributed
application, but here's the full code for a "fortune cookie" service.
First, declare the interface in IDL:
// fortune.idl
module Fortune {
interface CookieServer {
string get_cookie();
};
};
Now convert it to Python declarations with your chosen ORB's IDL
compiler, for example with omniORBpy:
$ omniidl -bpython fortune.idl
[ orbit-python doesn't have the IDL compiler step -- it always
compiles it on the fly. ]
First the client, on the Python command line:
>>> import CORBA, Fortune
>>> orb = CORBA.ORB_init()
>>> o = orb.string_to_object("corbaloc::spud.uk.research.att.com/fortune")
>>> o = o._narrow(Fortune.CookieServer)
>>>
>>> print o.get_cookie()
Objects are lost only because people look where they are not rather than
where they are.
>>> print o.get_cookie()
"I'd love to go out with you, but I'm staying home to work on my
cottage cheese sculpture."
There really is a fortune cookie server running on
spud.uk.research.att.com, so you can run this example.
Now the server:
#!/usr/bin/env python
import sys, os
import CORBA, Fortune, Fortune__POA
FORTUNE_PATH = "/usr/games/fortune"
class CookieServer_i (Fortune__POA.CookieServer):
def get_cookie(self):
pipe = os.popen(FORTUNE_PATH)
cookie = pipe.read()
if pipe.close():
# An error occurred with the pipe
cookie = "Oh dear, couldn't get a fortune\n"
return cookie
orb = CORBA.ORB_init(sys.argv)
poa = orb.resolve_initial_references("RootPOA")
servant = CookieServer_i()
poa.activate_object(servant)
print orb.object_to_string(servant._this())
poa._get_the_POAManager().activate()
orb.run()
That's it. Note that about half the lines of code are nothing to do
with CORBA -- they're just getting the fortune cookie. When you run
the server it prints a long hex string like:
IOR:010000001d00000049444c3a466f7274756e652f436f6f6b69655365727665723
a312e300000000001000000000000005c000000010102000d0000003135382e313234
2e36342e330000f90a07000000666f7274756e6500020000000000000008000000010
0000000545441010000001c0000000100000001000100010000000100010509010100
0100000009010100
which can be given to orb.string_to_object (without the line breaks).
That IOR string is also the server running on spud.uk.research.att.com.
A version of the server that can be used with the corbaloc URI is just
as simple, but omniORB specific, so I haven't shown that.
Stephen
the web for layman's (or at least novice programmer) guides to CORBA and
just in case anybody else finds themselves having to follow the same steps,
one of the best I've found is
http://developer.java.sun.com/developer/onlineTraining/corba/
don't worry about it being written for Java, it's the most simplified
I've found, assuming no prior knowledge of CORBA and accompanying jargon.
Now, in order to test your example, I've downloaded OmniOrbpy and am
about to install OmniOrb 3.x, as described at
http://www.uk.research.att.com/omniORB/omniORB_3/README_win32.html
It specifies that the pre-built binaries work for winNT/98 and uses
Python 1.52. Will try with win2000 and Python 2.1 but was wondering
if you know of any changes/differences ?
Thank you again for the example you provided,
Stephen.
Duncan Grisby
>Now, in order to test your example, I've downloaded OmniOrbpy and am
>about to install OmniOrb 3.x, as described at
>http://www.uk.research.att.com/omniORB/omniORB_3/README_win32.html
>It specifies that the pre-built binaries work for winNT/98 and uses
>Python 1.52. Will try with win2000 and Python 2.1 but was wondering
>if you know of any changes/differences ?
That page is talking about the Python requirements for the C++ version
of omniORB. If you only want to use Python, you don't need to install
the full version of omniORB 3. The omniORBpy binaries contain
everything you need.
There are pre-built binaries of omniORBpy for Python 2.1 on Windows.
If you use the Python 1.5.2 version of the binaries with Python 2.1,
Python will crash horribly.
Cameron Laird
Stephen <shr...@gmx.co.uk> wrote:
.
.
.
>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).
.
.
Your parenthetical comment ... well, yes, that
*certainly* is true.
People *do* use Delphi and VB plenty, even in
the present.
If you can make enough assumptions about your
Web client (that Java is enabled, and/or that
you're using Netscape and you are willing to
indulge in tricky multipart programming, and/or
...), you can get enough state to be useful.
A lot of people would say at that point that
you might as well do client-server without Web
weight.
--
Cameron Laird <cla...@NeoSoft.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html