2007/4/25, Jon Keating <[EMAIL PROTECTED]>:
Just some responses to your questions. For the most part, what you said is what we have talked about :)
That was the plan :)
within the pipeline as the worst case. So, what do we do? We'd have to save the original message so Licq can be re-run to decrypt the message. So, until the last plugin succesfully handles the event, we should keep a copy around just in case. As for a timeout, I don't
I think this is a good idea. But the question is how we will do this? The first idea that pops up is to save every event to disk, update it after each plugin in the pipeline (since a plugin may alter an event) and remove it from disk once it has been acked. This sounds easy but may not be the best thing to do performance-wise. A better idea may be to catch all fatal signals (SIGTERM etc) and save the active state and active events then. Of course, this wont work in case of power failure, but I don't think that's a big deal.
from losing the data. Of course, it is easy to say here, but that is ideally what I want.
Me too.
Definitely allow pointers. If we have large objects, we don't want to be having expensive copying operations throughout the pipeline.
The event is always passed as a pointer, so there wont be any copying done inside the pipeline. Except in getProperty where a copy will be made of the value. But we can change that to return a pointer instead. The real problem is if we allow pointers to be stored in a event. Who is responsible for freeing the object? How do we store it on/restore it from disk? // Erik -- Erik Johansson http://ejohansson.se/
