Wouldn't it be easier, both for plugin developers as well as the core, to just implement the /pre option as follows:
1 ) All plugins that register for "pre" messages will get them.
2 ) If any of the plugin's return TRUE then the packet doesn't reach the core GUI
The above approach gives the plugin maximum flexibility to both 'peek' at packets and allow normal processing to continue as well as trap packets so that the core client doesn't see them.
For example:
Client A makes a phone call to Client B. This process generates a Jabber 'Phone' message which Client B's plugin traps and invokes a custom dialog. (Client B's plugin notes the jabber id and transfers the call to voicemail)
Client A now tries to IM B. B can now choose to 'pass' the message through to the core or not.
Requiring plugins to filter shouldn't be too bad given the availablity of XML parsers. Also the nice thing about XML is that the namespace stuff makes it pretty easy for plugin's to coexist.
-Fred
-----Original Message-----
From: exodus-dev-***@jabberstudio.org
[mailto:exodus-dev-***@jabberstudio.org]On Behalf Of Peter Millard
Sent: Tuesday, February 03, 2004 1:20 PM
To: Exodus development
Subject: Re: [Exodus-dev] 'Private' messages in Exodus
Post by Fred O'LearyI'd like to be able to deliver messages to Jabber clients and have a custom
plugin control the UI appearance. I.e. I don't want message dialogs or
headline alert dialogs. For example when an instrument sends a 'private
message'to the jabber client, I want to present a custom dialog.
OK... So I was thinking about this problem and I think the solution is to create
multiple dispatch signals which represent different "chains" through the client.
When you register to catch packets coming in from the socket/server, you would
use the appropriate signal to catch those packets. (Right now, there is only a
single signal: /packet).
My initial thought is that there would be at least 4 signals:
/pre = catch stuff before anyone else (pre-processing)
/special = catch stuff based on pretty fine-grained xpath statements. This would
include things like all x:data messages, MUC invites, etc.. Used somewhat by the
core client, but also by plugins a lot to catch specialized packets (This is
where you would want to hook in, Fred).
/packet = Normal processing... used a lot by the core client.
/unhandled = No one else caught the packet. This would be for "last chance"
processing, like general message type="error" processing, etc.
The magic part is that the next signal would ONLY fire if the packet was not
caught by any of the listeners to the current signal. If a packet is caught, all
listeners to that signal still catch it, but ithe packet would never make it to
the next signal.
For example, a plugin would register for:
/special/message/x[@xmlns='http://pgmillard.com/jabber/foo.xsd']
If a message comes in that matches this xpath, then my plugin would get it
before the core client could does, so my plugin can pop-up a custom GUI. Since
the packet would never make it to the "/packet" signal, the normal GUI would
never pop up.
BTW, this would also simplify some special case logic that currently exists in
the client, and would make things a lot more modular.
This is all super easy to implement, my only concern at this stage is the
"coverage" of those 4 signals.. Are they enough to catch all possible
circumstances? Potential plugin authors, please speack up :)
pgm.