A Python application server?

[Duncan Smith]

"Irmen de Jong" <irmen at -NOSPAM-REMOVETHIS-xs4all.nl> wrote in message
news:3edb9bf2$0$49104$e4fe514c at news.xs4all.nl...
> Duncan Smith wrote:
> > Hello,
> >          I'm trying to put together a (basic) design for an online
> > examination system.  The system already exists, but is based on Java
> > technologies.  I have (probably prematurely) assured the author that the
> > system could have been developed in Python.  This is based in faith
rather
> > than reason, as I have never had cause to consider such a thing before
> > (although I can now envisage that I might need to develop a simple
> > application server within the next year or so).
> >
> > Having looked at PYRO, Twisted and WebWare I'm pretty confident that
most of
> > the technology is in place.  But I have been told that to emulate the
> > existing system there would have to be a Python equivalent of an
'untrusted
> > Java applet'.  (I'm not convinced this is actually necessary for the
given
> > app., but the existing system does use RMI and Java applets.)
>
> Pyro is no "application server", it's more an enabling technology. Compare
it
> with Java's RMI (but easier to use :-) ). Sure, Pyro contains a builtin
> server to dispatch incoming remote method calls to your own code, but it
> doesn't help you build a really complex system. Then again, you are free
to
> build it the way you want: small & lean if that's all that is needed,
large
> and complex if that's necessary, where Pyro fulfills the communication
needs.
>
> > What I'm basically trying to address is the following statement (from
some
> > of his lecture notes):
> >
> > "Java is the only mainstream technology that adds the required level of
> > safety for code travelling around a network, and the flexibility to
invent
> > our own controls, regardless of the operating system being used."
>
> Pyro supports mobile code with a few technical limitations. There is NO
> security involved other than host-based and passphrase-based
authentication
> (no sandboxed code or whatever).
>
> > Forcing the client(s) to install much software is apparently out of the
> > question (so no Grail / Python applets).  Any suggestions?  Cheers.
>
> Will a web-based solution work (pure HTML pages)? Then all you need is a
web
> browser on the clients. Leave all the difficult stuff on the server.
>

At then end of the day, I think so.  I think he currently uses an applet
because he wants to display a clock for his students' benefit.

Duncan