AJagucki.log

Work on implementing XEP-0163 in Openfire is nearly complete. Its current state is very usable now that PEP service auto-subscribe on presence subscriptions has been included in a revision I committed earlier in the week.

Contact Subscriptions

A subscription to a PEP service's root collection node (and thus all leaf PEP nodes) is generated and processed by the server during two different situations. The first instance can occur if user Foo has a PEP service in memory on the server and user Bar decides to subscribe to Foo's presence. Upon Bar's presence subscription being authorized, a subscription to Foo's root PEP node is automatically created by the server. The second instance occurs when both of our example users already have established presence subscriptions to each other, but neither have a PEP service created yet (since PEP services are virtual and are actually created dynamically in Openfire as the need arises for efficiency purposes). Once either user decides to publish some personal eventing data and a PEP service is created on the server, anyone who already has a presence subscription to the owner of the new PEP service automatically gets a subscription created for the owner's root PEP node as well.

With the Contact Subscription section of XEP-0163 now implemented, testing with PEP supporting clients like Coccinella and Psi is much more viable (before this point, raw packets needed to be created and sent manually for PEP service/node subscriptions). Below are screenshots taken during my latest tests, including tests for publishing User Geolocation and User Activity data to Openfire using Coccinella. There is also a shot of my friend buchan (aka Jared Hendry) publishing his User Tune data taken from iTunes using Psi.

Next week I will be implementing the last couple sections of the XEP, starting with Contact Notification Filtering.

Client Tests

Publishing geolocation using Coccinella:

Viewing geolocation in Coccinella:

Viewing geolocation in Psi:

Publishing user activity using Coccinella:

Viewing user activity in Coccinella:

Viewing buchan's tune in Psi:

Over the last few days I finished implementing Contact Service Discovery. Doing so was not as straightforward as I thought it might be. I once again needed to extend Openfire's API with the introduction of a new class I called UserItemsProvider. I then needed to modify IQDiscoItemsHandler so that it would accumulate items from all implementers of UserItemsProvider anytime a disco#items query was sent to a user's JID. The default discoverable items for a user include every resource they can be addressed with (if the disco#items query came from someone with a bidirectional subscription to the addressee's presence). These default items were hardcoded into IQDiscoItemsHandler, so I refactored it some to make use of the new UserItemsProvider interface. Ultimately, this allowed me to make IQPEPHandler an implementor of UserItemsProvider as well, enabling me to provide PEP nodes as items while respecting the access models in place for each node.

With all of this done, I went ahead and created the same Shakespearean dummy users as those in the examples for the Contact Service Discovery section of the XEP. Everything worked out as planned, with the access models being respected for each disco#items query. Check here for a complete log of the XML console during my tests.

However, this was only after I discovered and corrected what I believe to be typos in XEP-0163 in which access models are set within fields surrounding <value> elements with superfluous <option> elements. After checking the mailing list I discovered that others had encountered this as well. As this thread explains, everything works as expected when the seemingly needless <option> elements are removed in the example node creation packets. As Peter Saint-Andre has told me before, there is a newer version of XEP-0163 being finalized which does not suffer these same typos. I will bring this little issue up during our next GSoC meeting in jdev@conference.jabber.org just to be sure I and those from the mailing list correctly assumed the example packets to contain typos. Since Openfire's node access model configuration code works as expected without the <option> elements, I agree with those from the mailing list that it was probably a typo.

With another section from XEP-0163 implemented, my goal for next week is to attack the next section: Contact Subscription. Currently, PEP nodes can be subscribed to with explicit pubsub subscription packets, but I will need to implement the auto-subscribe with presence functionality as well.

When Contact Subscription and Contact Notification Filtering are finished, I will be very close to done with the complete implementation of XEP-0163. Any extra time left in the summer I will likely spend implementing the new versions of XEP-0163 and XEP-0060. Why would I stop when I am having this much fun?

Last week's refactoring of the PubSub framework underwent a more thorough testing and verification for compatibility with PEP. With the changes working as planned, much progress was made towards completion of the implementation of the actual protocol specification (as opposed to implementation of the architectural design of PEP in Openfire).

At the beginning of this week, the PEP implementation was at a stage where I could make use of Psi's preliminary PEP support to test with Openfire. When a user publishes his/her Mood in Psi, and the node they are publishing to does not already exist, their PEP service must automatically create the node. After I setup this bit of logic in my IQPEPHandler, I was able to give Psi's mood support a try. Below are screenshots of the trial along with Psi's XML console output.

Publishing mood with PEP:

Viewing the node contents in the contact tooltip:

XML Console Output:

<iq type="set" id="aabda" >
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<publish node="http://jabber.org/protocol/mood" >
<item id="current" >
<mood xmlns="http://jabber.org/protocol/mood">
<flirtatious/>
<text>Denise is near...</text>
</mood>
</item>
</publish>
<configure>
<x>
<field type="hidden" var="FORM_TYPE" >
<value>http://jabber.org/protocol/pubsub#node_config</value>
</field>
<field var="pubsub#access_model" >
<value>presence</value>
</field>
</x>
</configure>
</pubsub>
</iq>


<iq type="result" id="aabda" to="ajagucki@127.0.0.1/Psi" />


<message from="ajagucki@127.0.0.1" to="ajagucki@127.0.0.1"
         id="http://jabber.org/protocol/mood__ajagucki@127.0.0.1__g1tc1" >
<event xmlns="http://jabber.org/protocol/pubsub#event">
<items node="http://jabber.org/protocol/mood" >
<item id="P1tcu6gwk9RQChT" >
<mood xmlns="http://jabber.org/protocol/mood">
<flirtatious/>
<text>Denise is near...</text>
</mood>
</item>
</items>
</event>
<headers xmlns="http://jabber.org/protocol/shim">
<header name="pubsub#subid">yShj3lEQl1F8kjoI1ag7XYP41pbyNaysqNAOVn76</header>
</headers>
</message>

Below is a table that gives an overview of which sections in the specification have been implemented and verified for correctness. One should keep in mind that some of the work that appears to be incomplete may already be implemented in Openfire's PubSub framework, requiring only minor tweaks to be considered implemented for PEP.

If you wish to follow the progress even more closely, you can checkout the latest revision from my PEP branch in Openfire's svn repository (thanks Gaston ):

svn co http://svn.igniterealtime.org/svn/repos/openfire/branches/pep

Refactoring PubSubEngine

Between now and my last post I have spent most of my time improving upon the (not so efficient) design for PEP that was in place. As it was previously, each user's PEPService had its own PubSubEngine to handle the actual underlying PubSub related work involved with PEP. Consider the memory overhead incurred if there are 100,000 users each with their own PubSubEngine that is performing the same exact PubSub functions. Clearly this is a waste of memory. However, the PubSubEngine was designed in a manner so that it was deeply intertwined with a single PubSubService instance which was one of its member variables.

In one of my previous meetings with Gaston we looked at the feasibility of abstracting out the PubSubService from the PubSubEngine in an effort to allow every user's PEPService to work with a single PubSubEngine from within the IQPEPHandler. Unfortunately, it was not a very trivial change to make. There were a number of class variables in PubSubEngine whose constructors required a PubSubService. A lot of code was modified or moved elsewhere from PubSubEngine. More than I expected in fact. Of course, the PubSubService interface along with its implementors (PubSubModule) needed to be modified as well to accommodate the changes made in this major refactor.

As arduous as it was, I have completed this refactoring and Openfire happily compiles and runs. It would have been nice to have unit tests available for the PubSub framework in place already, but that is not the case. If there are any bugs introduced from the refactoring I will take care of them as they are encountered with my own tests as I continue implementation of XEP-0163. Although my task may be more difficult as a result, the savings in memory overhead on large deployments will be well worth the effort. Gaston said this refactoring would be the hardest part of the project, so it is a relief to have completed it. The implementation from here on out should be fairly trivial.

Goals

My next few goals are as follows:

• Make PEPService implement the Cacheable and Externalizable interfaces for even more efficiency.
• Create PEPServices dynamically when a user attempts to utilize PEP. This ensures we only allocate PEP resources for those users interested (instead of preallocating resources for every user).
• Make adding 'identity' elements to the server's disco#info result dynamic in the same manner that is done for features.
• Proceed with implementation.