Hi! The first problem I saw with Pyro Event Server is that it seems to me too complex for the task. Django uses PyDispatcher as the in-process event subsystem. In order to make the event objects network-dispatchable, the only thing that should be done is to find a way to serialize events somehow, send the string (serialized object) over the net, restore them on the other end of the wire, and, the most interesting part, trick PyDispatcher into thinking that the event object that was wired over the net was really equal to the in-process event object that was subscribed to by in-process handler. The common way to serialize/deserialize python objects - pickle - that is also used in Pyro, does not help. While You are guaranteed that when any picklable object is restored, it will be workable. But the restored object won't be *equal* to the object that was pickled in the first place - they would be definitely different objects. When the event is registered with PyDispatcher, the event object is hashed and the hash is used to build a mapping to the listeners. When the event is fired somewhere in the process, the hash of the fired event object is used to find the listeners in the event mapping by the key with the same hash value. The common way to hash objects and to is to test objects for equality is by their memory address. The trick is to make a base class for dispatchable objects (I call it Dispatchable), that override comparison and hashing of the object so that any objects of the same class (that is Dispatchable or the subclass of Dispatchable) are considered equal and have the same hash value. In order to wire the event object to another process it is sufficient to pass the module and class name to be able to instantiate the event class on the other side. That's all. The code in Process 1 subscribes to the Dispatchable instance. The code in Process 2 triggers the Dispatchable instance, it is wired over the net, and we have another Dispatchable instance in Process 1. It is sent to PyDispatcher. As all the Dispatchable instances are concidered equal, the handler in the Process 1 is successfully invoked. Simply enough. I don't see how Pyro can help better with this case. The other thing Pyro can help with is the event arguments. Indeed, the current prototype deals with immutable arguments only. But that's not because of I can't use pickle. The mutable object that is passed to the event in-process would be not the same object that would be restored from pickle at the other side, and that's the problem. We will introduce the object that looks the same as in-process, but it will reference different memory address, and if side effects envolved when the object is passed to the event handler, we are just looking for trouble. That's why I don't like anything mutable passed as an argument to the event that should be transfered over the net. So, it seems to me that using Pyro as an event transport in this case cause unnecessary overhead with questionable consequences. If Django didn't use PyDispatcher, Pyro would be an option, though. Maybe I am mistaken, but that is the case for me just now.
The second problem with Pyro Event server I saw in the ES manual (http://pyro.sourceforge.net/manual/6-eventserver.html): "Another thing to pay attention to is that the ES does not guarantee delivery of events. As mentioned above, the ES does not have a store-and-forward mechanism, but even if everything is up and running, the ES does not enhance Pyro's way of transporting messages. This means that it's still possible (perhaps due to a network error) that an event gets lost. For reliable, guaranteed, asynchronous message delivery you'll have to look somewhere else, sorry ;-)" Maybe this is only a disclaimer, but I didn't dig further. Spread seems to guarantee more. Regards, Max --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
