Provider Architecture: searching for Smack style, culture, and idiom

Smack Smack Dev
1

Good day.

I am working with Smack and the Smack Provider Architecture for the first time. This makes me a man in search of the best Smack culture and style.

I have walked myself down a path whereby I have implemented an IQ subpacket processing by implementing the IQProvider interface. This IQ subpacket contains multiple XML subdocuments.

My IQProvider on paper munches its way through ****

the entire subpacket

, parsing the enclosed XML subdocuments along the way.

In parallel, I added my ****
iqProvider

element to my smack.providers file. And while I was at it, I added ****
extensionProvider

elements for the subdocument processing hooks.

The model contradiction I have created for myself it seems is in my IQProvider processing the entire subpacket, yet at the same time the smack.providers file contains hooks that describe how to help with processing the same subpacket.

I’'m missing some basic Smack physics and culture. Should I process the entire subpacket in the IQProvider implementation, assuming I can? If I can and should, do I need the extensionProvider elements in the providers file?

With a few more hours of study I will have this. But any words of wisdom or guidance on how to think about structuring the parsing code is most welcome.

2

IQ provider sounds like what you want to implement. There’'s two models:

  • IQ always carries a payload of some custom type. Therefore, there’'s a provider architecture just for IQ packets.

  • Message, presence, etc can optionally contain custom payloads. That’'s what the extension providers are for.

So,

IQ packet --> IQProvider

Any other type of packet --> extension provider

I hope that helps!

-Matt

3

Thank you.

I’'ll take this to an extreme, hoping I can pay it off by posterity benefitting from my lack of understanding.

Here is a more specific phrasing of my current challenge.

  1. I understand that the smack.providers file functions as a list of hooks. Or a list of handlers, if you will.

I have not read the low level XMPPConnection code, but I can imagine that when that low level code receives a subpacket for which there is no native handler, a call is made into the list of hooks in the providers file, looking for an IQProvider match. Fair enough.

Having an idea of how the IQProviders are hooked in, what I still don’'t understand is this: I have not seen where in the code the calls are made to take advantage of an extensionProvider in the providers file.

This lack of understanding is all in the context of parsing an input stream just taken off the network, and not in taking a Java class instance and converting it to the associated XML representation for outbound network transport. I assume the various toXML() and getChildElementXML() themes address that.

So…

  1. My first attempt to understand how the providers file facilitates the hooks to help parse extensions came with a review of

org/jivesoftware/smackx/provider/DiscoverItemsProvider.java

which I discovered and which became interesting soley on the basis of looking for and finding it as a reasonable subject of study in the providers file.

  1. So I commenced reading the source for DiscoverItemsProvider, expecting to see some call which belies how the providers file hooks are called upon in parsing the stream represented by “parser”. In other words, I expected to find some sort of indirection layer in DiscoverItemsProvider, but instead I found none.

If I read it right, DiscoverItemsProvider parses the entire custom packet in full local view, explicitly creating new DiscoverItems.Item as it encounters them. DiscoverItemsProvider doesn’'t use the information in the providers file to my eye - it manages the “new DiscoverItems.Item(…)” itself.

So I am left still wondering what layer of code uses the extensionProvider information in the providers file and how does that code call the handler code? The DiscoverItems.Item handler information is certainly available to DiscoverItemsProvider, but the latter almost certainly has been coded not to avail itself of it. This cannot be accident, but it would be helpful to see sample code that uses the extensionProvider info in the providers file, and therefore hint at when such calls to the handler code are appropriate.

Thank you.

Mark

4

I believe I have found where to hunt for the answers to my questions: the IQ.parsePacketExtension() and Packet.getExtension() methods, and perhaps surrounding logic.

Thanks.