I have some really old hardware clients that use ‘‘ready’’ instead of available. I would like to either add a custom presence type to the server so that it understands ‘‘ready’’ as null / available.
Or, add a plug-in that filters the incomming raw data and exchanges any occurance of ‘’>ready<’’ with ‘’>available<’’ before the data is processed by the server.
I am comfortable with writing the plugin, but would ask some advice on the best place to hook the plugin… Will a packet interceptor actually be able to change the presence status messages in this way, or do I need so lower-level customization??
Maybe somewhere there is a flow diagram showing the order of processing?
Unfortunately, a packet interceptor is likely too late to transform the data. Wildfire will reject “ready” as a presence type when turning the XML into packet form (before handing off to interceptors).
Two options I can think of:
Hook into the XML processing and modify the content there.
Customize the presence packet implementation and have it transform “ready” to available.
No chance of updating the hardward clients to send correct data?
as one usually don’'t update the Wildfire version every week patching the source should be an option for maxwin, is getType() in Presence.java the right place?
I also have some difficulties to follow the flow a packet is routed in Wildfire itself. As it is open source adding some Log.debug() statements is easy possible
I had already tried to modify the getType() and getShow() methods in Presence.java - it almost worked but not quite. The server would show online correctly, but other clients still see them as offline, and thus cannot subscribe.
I am thinking matts idea about hooking the XML will be the best before the packet is created and added to the server flow.
Any tip about the earliest point I can get the raw data to modify would be appreciated. I guess in one of the socket listeners immediately after the data arrives?
You would need to modify the actual packet creation in the constructor of the Presence packet – look for the XML in the Dom4J element and then modify it. I think the problem is that sometimes getType and getShow are used, but other times it’'s using the raw Dom4J packet data.
We are looking into different XMPP presence servers. One of our requirements is to be able to extend the presence type natively supported:
From the documentation we see that the following presence conditons are supported:
Presence.Type.unavailable – signals that the entity is no longer available for communication.
Presence.Type.subscribe – the sender wishes to subscribe to the recipient’s presence.
Presence.Type.subscribed – the sender has allowed the recipient to receive their presence.
Presence.Type.unsubscribe – the sender is unsubscribing from another entity’s presence.
Presence.Type.unsubcribed – the subscription request has been denied or a previously-granted subscription has been cancelled.
Presence.Type.probe – a request for an entity’s current presence; SHOULD be generated only by a server on behalf of a user.
Presence.Type.error – an error has occurred regarding processing or delivery of a previously-sent presence stanza.
Is there a way we can extend the list above? Can we use OpenFire APIs in order to change the presence condtion on the server based upon our rules engine?