Pyro 4.0 development
Pyro 4 is under development and not a finished product yet
If you are looking for a stable version, have a look at Pyro v3 on the FrontPage, or project website.
Pyro 4 will be a full rewrite
I've decided to rewrite Pyro 4 from the ground up. Using only little bits of code from the older version. But once it will be released it will be a standalone product. The old Pyro CVS code repository will not contain the Pyro 4 version, it will only live on for Pyro 3.x versions.
The only code branch that is useful or relevant in the CVS repository is the 'v3_maint_branch' branch. Don't use the trunk. That was going to be Pyro 4 but I've changed my mind.
New Pyro 4 website
Pyro's new web site and manual will be built on this wiki first for the time being. Topics:
/Migration - migrating Pyro 3 code to Pyro 4.
Current issues
There seem to be some strange problems using the poll function from the select module in Jython. Once the first connection has been made, the server socket will forever trigger the poll function even if there's no new connection available. The accept() call that is done will fail. This problem does not occur on Mac OS X. (and Windows uses select).
The NS on Jython has problems when using threadpool server. It doesn't respond to request properly. If you disable the bc server (-x) it works fine. (seems to occur on Mac OS only, windows seems ok)
Things missing
- unit tests for dotted names needs a server with dotted names enabled
thread pool server: min/max number of threads, shrink and grow dynamically (see Sneaky) + fix jython issue with Name server
- "if you need to resolve lots of objects, consider using the name server directly instead of Pyro.naming.resolve"
- "remember that URIs in proxys are unchanged. If you use many 'meta' uris (with PYRONAME or PYROLOC) Pyro has to do a lookup everytime it needs to connect. Consider using PYRO uris or obj._pyroBind() if you want to avoid all the lookups."
Ideas
- change startNS so that you can start the proper requestLoop in your own code (startloop=False?)
- callback objects: raise exception locally as well instead of only silently returning it to the server
- connection validator is missing and I want it back with similar features as Pyro3
- persistent Name Server (store namespace in a database on disk, use sqlite)
- session handling in the server (something like TLS but less sucking)
- clean way to have server hooks for client connects and disconnects
- build an asyncore/asynchat mainloop for a non-threaded server
"Callbacks: when registering a callback object *once*, deadlock may occur if the objects enter a 'conversation'. For instance: if A calls B, and B calls back to A trough a callback object, and then A tries to call B again --> deadlock because B is still waiting for A to answer the callback invocation, not invoking a method again! When A does not call B again but just answers the callback invocation, things work out fine. See bounce2 code in the examples. Solution???: Pyro must detect that the connection is still in use (waiting for reply) and it should open a new connection for the new method call."
- investigate alternatives to m2Crypto for SSL support (pyOpenSSL? use egenix' version for easy installation)
