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?