PEP events vs Pubsub events

Smack Smack Dev
1

Hi all,

Like others before me, I am working on getting PEP events and Pubsub events to work as stated in the relevant specifications. I’m using User Tune as a test case for now, and am producing PEP Events that match the spec, but as has been noted before, they are mangled by PEPProvider, which strips off the event element and the items element, leaving the delivered message malformed.

Since the PEP spec inherits the schema from Pubsub with respect to events, the resulting message has a nearly identical form between these two cases. When I registered the PEPProvider, it became the provider for the (“event”, “http://jabber.org/protocol/pubsub#event”) element/namespace combination. Reading the spec more closely, it appears that the only distinguishing characteristic between the Pubsub event message and the PEP event message is the node to which the event is associated.

As an experiment, I removed the PEPProvider registration, which allowed the incoming message to be processed as a Pubsub event. This eliminated the mangling of the message, and it was then picked up by the PEPManager as expected, but left me with a ClassCastException when PEPManager tried to cast it to a PEPEvent for delivery to my registered PEPListener. This is easy enough to fix, but brought up a more important question: At what point in the packet processing should the type of these events be distinguished? The node name seems like the best way to disambiguate the two, but should this be handled in the parser, or would it be better to parse the extensions completely, then use the node name to route the resulting message to the proper listeners?

Steve

2

Unfortunately, PEP and pubsub are not actually compatible within Smack. Pubsub was written after PEP, and thus PEP does not use the pubsub module (as it should, since it is a subset of pubsub). Right now, it is an either/or for usage until I can refactor PEP to use the pubsub module.

That being said, you may be able to accomplish PEP via the pubsub API by setting the to address when you create the PubsubManager to the users JID, instead of the pubsub service. Please note, I have never actually tried this.

3

That makes sense. I have been coming to the conclusion that most of the PEP-specific classes were unnecessary, so I have been working in the direction of refactoring to eliminate the unnecessary classes (e.g. to use EventElement instead of PEPEvent).

It seems that the best approach is to parse the messages first, then use some combination of the from address and the node to distinguish between PEP events and Pubsub events. This would pretty much eliminate everything except the PEPManager.

If you have any interest in using the changes I am making in the refactoring effort, I’m more than happy to provide them in whatever form is useful to you.

4

You are correct, there are no actual PEP events, there are only pubsub events. Refactoring of PEP would likely lead to nothing more than a convenience class (a new PEPManager) that utilizes the existing pubsub API. It may even be possible to simply incorporate it into the existing PubSubManager.