Hello, First to say: The event handling looks nice and much more flexible than the callback routines which are used atm. :)
Am Mittwoch 25 April 2007 20:05 schrieb Erik Johansson:
> > 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?
I'd say definitely No here. Not only do pointers yield the problem of
ownership (who has to delete the pointer and who must not), but also they are
context sensitive.
Imagine the daemon and plugin running in different processes, as would be
possible with the socket connection, or even on different machines, if the
communication is done with some IP. A value could always be transferred
between those domains, but a pointer will be invalid as soon as it leaves its
own process.
Also, a pointer cannot be serialized, i.e. stored to a file as was proposed in
case of failures. If a class containing pointers is to be stored, it has to
bring its own serialization and deserialization routines, which IMHO is
beyond the scope of licq event handling.
I suggest to disallow pointers for the event properties. The resources needed
to copy values are spent well for a much more flexible architecture.
> The daemon will order all plugins interested in event X in a queue based on
> their priority. When an event arrives, the plugin with the highest priority
> will get it first. When it is done, it is passed on to the next plugin and
> so on. This way, an encryption plugin gets a chance to decrypt the message
> before it is passed on to the history plugin and then the gui. When the last
> plugin in the chain is done with the event, it is sent back to the sender as
> a way to ack the event.
If there is another plugin which should get the event before the encryption
plugin (p.e. some spoof protection), how can this be registered? The highes
priority would be already taken.
Maybe this can be solved by using some more relative way of specifying the
priorities. Atm I do not have the ultimate solution to this problem, but
absolute priorities will yield in conflicts, I believe.
Greetings,
Stefan
--
____
/ \
/ ^ ^ \ Stefan Haun
I \/ I [EMAIL PROTECTED]
II II http://www.tuxathome.de
II II
I /\/\ I
pgp7zxhGjOfOF.pgp
Description: PGP signature
