> - Java (and possibly Jython) or Mono/C# (or possibly IronPython) on the > server. Requirements are: A strong and fair threading model. This is > actually what drove me away from Perl and what essentially prevents > using a normal Python interpreter on the server. I don't know whether > the GIL and starvation issues also apply to IronPython or Jython. > Sharing non thread-aware objects of arbitrary type between threads > without any restriction is absolutely necessary (this is not possible > in Perl).
I'm not sure which configuration you want to change how often. But I'm not convinced that the python threading limitations really do make a difference here. Do you really benefit from multi-core capabilities in this scenario? Because that's what you are asking here, and somehow I doubt that all of a sudden the bazillion of single-core-servers that suited us so well are a major PITA, together with all the apps running on them. > - Perl or Python on the client side. Clients have to provide a UI (a > web application is not an option). > > Unfortunately, I have very little experience with client/server > architectures and the protocols involved, so I would like to collect your > recommendations as a starting point for further research: > > - Are there any standard protocols that make it easy to share objects > between Java/Jython/IronPython and Python or Perl over the network? I > am thinking of a portable, language independent object > (de-)serialization, if such a thing exists. > Having a defined protocol/interface between the client and the server > that makes it easy to switch technologies on either side of the > architecture is a strong requirement. > > - How does bi-directional communication in such a protocol work? I am > assuming that the client should not poll the server for callbacks, > OTOH, leaving a TCP connection open also does not seem right. > > - What is the security model of that protocol? > > If my description of the project is inaccurate or too incomplete I > apologize; the problem is that I still find it hard to tell which > requirements actually matter. > > If you have any pointers that might be of interest for such an > architecture, please let me know. Sounds like CORBA to me. CORBA has a very mature and good implementation for Python called OmniORB, and interoperability with other orbs (the ones available for e.g. Java) is very good - as CORBA as standard is mature. Having call-backs and the like is also no issue in CORBA. However, it is _not_ serialization of objects, just RPC - you expose an object living in your server to clients. It's not transferred. And the other way round, you can pass client-side object references to the server and call these. I can't comment too much on the security aspects, but AFAIK at least SSL is an option. And from what I know about SOAP it's certainly not better suited (besides the fact that it sucks big time anyway) HTH, Diez -- http://mail.python.org/mailman/listinfo/python-list
