Pyro 3.9.1 is the current release

All users of 3.9 please upgrade, it is a drop-in bug fix release. Find it on Pyro's SF project page if you don't pull the release from CVS.

The changes since the previous release can be found in the 'changes' chapter in the manual.

Pyro's TODO list

This is my TODO list. If you have a solution for an item on this list, or if you have a topic to add to this list, please add it and mark it clearly and/or drop me an email-- irmen (at) users.sourceforge.net

• initTLS needs to change to be more useful than just a init function. Pass an object with a callback method so that you can associate
  • data with it as well, and make it customizable for every Pyro object instead of 1 global thing for the whole daemon.

• move caller from TLS to someplace on the objBase class instead (but how can delegate get it then?) - then get rid of TLS usage in Pyro

• change order in attr lookup in delegates, so that you can actually override methods from the delegate in the objbase
• change objBase constructor to take another object that it needs to wrap as delegate, instead of using delegateTo

• SSL/M2Crypto issues: (tested against M2Crypto 0.18.2 from http://chandlerproject.org/Projects/MeTooCrypto)

  • ssl socket recv() doesn't support extra parameters such as MSG_WAITALL. So _recv_msg() in protocol.py has to specialcase this for ssl sockets

  • m2crypto ssl sockets return None on recv() when socket.setdefaulttimeout() has been set, this causes ConnectionClosedError

  • select doesn't work on M2Crypto's SSL sockets if there are still bytes pending. (it doesn't return the socket)

• change select calls to poll if available (and test on jython/ipy!) - patch in mailbox
• Event server producer/consumer don't need to copy the proxy all the time because nowadays proxies contain thread locking
• option to not resolve URIs in place but always keep the original names such as PYRONAME:// uri
• be able to use a client-to-server socket to make callbacks back to the client (so that client doesn't need a deamon for this) This may require more general socket/connection management (pools?)
• use thread.get_ident() instead of threading.currentThread() to identify threads. Avoids certain obscure thread id problems. This requires an API change and code change as well because you can no longer pass threading.Thread objects to _transferThread() !
• improve daemon's object implementation map, its getRegistered method, and !ResolvePYROLOC (this one loops through the map in O(N) complexity .... I want O(1)

• investigate the 'devil number' on macos: DevilsNumber

• what about AttrProxy? And the new decorator stuff should be used for attributes as well (instead of allowing every attribute to be set/get)

• investigate other serializers (JSON? YAML? TrustedPickle, Cerealizer)

• ES: queueing of events when subscriber is too slow? Need max number of threads? (queue will block if its full, but threads keep on getting created)

• 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.

• repository in Subversion instead of CVS
• NS lookup using IP multicast

• implement PYRONAMESSL protocol? (see PYROLOCSSL) NS needs to be able to run in SSL mode.

• implement multicall methods (see Python's xmlrpclib) to do batch-invocations.
• clean way to have server hooks for client connects and disconnects (latter can be used for cleanups!)
• transient object cleanups; only clean when client disconnects?
• replace the argument passing code in the various script tools by a better one (getopt or even optparse), so that for instance the order of the arguments doesn't matter anymore.
• investigate alternatives to m2Crypto for SSL support (pyOpenSSL? use egenix' version for easy installation)
• Server to client authentication (Pyro does only client to server). My clients send some sensitive stuff to the server and I must be sure the reference I have for the remote object it's the one I'm supposed to talk to. (I didn't do it very nice, but simple, using python's hmac module - client makes a call to the object with token and compares the return value with it's own computation).

• For Pyro 4.0: see if PEAK can be of any use (naming service etc)

• nested attribute access via new NestedAttrProxy See XML rpc lib (in Python <=2.4.0, it was patched in later versions). Pay attention to this security issue here!! "you can traverse into the internals of an exported function and thus access func_globals and thus see private data. That data can be changed and deleted" !

• register more than one URI with the same name in the NS? So that essentially you don't get the single, unique service but a list of service instances, of which you can select one. Or perhaps provide your own load balancing plugin.
• add some form of regression testing that can run all (ideally) examples / tests. Perhaps a real test set is necessary. (the examples are just that-- examples, not test cases)
• Investigate possible protection of NS against overwriting existing object registrations. Describe in NS and Security chapters.
• ES topic lister + stats? Can only show topics for which there are listeners, ofcourse (including patterns). Stats might be accumulated over all topics ever used...
• NS: multiple object locations registered for a single object name (replication of pyro objects)

• Reaping transient objects doesn't close any socket connections that may still be active to these objects. They'll fail with ProtocolError 'unknown object ID' if they're accessed again. This is because sockets and threads on the server are not necessarily associated with a unique object, so they have to remain active. (Once the client closes the connection due to some error, the server side socket and thread will be released).

• Socket Connection pool on client side... max number of sockets to a specific host. Proxies to that host can pool the sockets. Multiplex calls from the same thread to the same pyro daemon over a single socket?
• Look into the multiple-protocol issue. Pyro depends too much on sockets. It should be possible to change that to Unix domain sockets, or other IPCs.
• Code cleanup; PYROAdapter/TCPServer/Daemon look like spaghetti. (still )
• Bridge to XMLRPC, SOAP. Store XMLRPC: or SOAP: uri's in Pyro's NS??? Do NOT attempt to process/store WSDL or act as UDDI server! Bridge must also accept incoming XMLRPC/SOAP requests and translate them to Pyro calls. For best results, a protocol mapping def. is needed