Since upgrading from Gloox 0.9.8 to 1.0.17, we need to have subclasses of StanzaExtension instead of just referring to the extension types using strings.
The existing code (using strings) is now wrongly casting the char* pointers to match the int argument of registerIqHandler:
Therefore, while it compiles, it is fundamentally broken until the extension stuff is done with subclasses.
clang builds in travis-ci fail outright due to this issue:
JabberComponent.cxx:150:40: error: cannot initialize a parameter of type 'int' with an lvalue of type 'const char '
/usr/include/gloox/clientbase.h:433:50: note: passing argument to parameter 'exttype' here
void registerIqHandler( IqHandler* ih, int exttype );
Some notes on how to proceed:
On Mon, Aug 22, 2016 at 3:50 PM, Jakob Schröter <email@example.com> wrote:
You will have to create your own class that handles that Apple stuff. Do so by inheriting from StanzaExtension. Have a look at its documentation and any of its subclasses for what to do in the member functions, it's really easy. Then, register that new StanzaExtension of yours with ClientBase::registerStanzaExtension(). You can then register the handler for that extension with Clientbase.
and an update on 2 November 2016:
And adding to that:
I would recommend to put your own derived class(es) into separate files, but it should also work if you leave it in the main class you're using, it's just more overhead.
The subclasses are linked to from the StanzaExtension documentation's top graph. Just pick any, e.g. DelayedDelivery:
In delayeddelivery.cpp:22 and :30 you see StanzaExtension is initialised with ExtDelay. You will have to chose your own value there, which must be bigger than ExtUser (all existing ones explained in https://camaya.net/api/gloox/namespacegloox.html#ac9367f9f59fa7917d4ac3553a3d5b1da) and should be unique for each derived class.
Set up filterString() according to your needs, ie. put in the namespaces you want to handle in that class. The filter understands some XPath.
One of the ctors (const JID& from, ...) handles the case where you want to add the extension to an outgoing stanza. In this case it basically stores the contents in internal variables which are then assembled into proper XML by the tag() function.
The other ctor (const Tag* ) is used to parse incoming XML when the above filter is triggered in ClientBase. What's passed to the ctor is only the matched subtree of the incoming stanza. Just parse it and store it for later access (you may have to provide getters).
See the docs for more details (e.g. newInstance()).
Now, to actually use this you have to register it with ClientBase::registerStanzaExtension(). Here, an empty instance of your class should be passed, which will act as a template later (by means of YourExtension::clone()).
You can now also register your handlers for the extensions you want to deal with, by using the exttype you used in your subclasses.
ClientBase will now check incoming stanzas against your filter string(s) and call the respective handlers.
Hope this helps. Let me know if you have any further questions.
Follow-up email sent to Balram and Jakob to see if any fix was coded and not yet submitted in a pull request