powered by Jive Software

GoJara Presence Pushing

I setup spectrum2, gojara using openfire 3.8.2 and use gajim as xmpp client, sadly the transports don’t go online if the account get’s online. I see that his behavior is documented at http://community.igniterealtime.org/docs/DOC-2601#Gajim_0154 but I am unable to locate the setting for presence pushing.

Furthermore I wonder what the offical XMPP protocol specification say about this topic. Do clients have to send the presence also the all registered components? Or is it’s the job of the xmpp server to broadcast the current presence to all components? The first seems to make more sense to me, since users may want to have different presences for their regsitered components.

Use gojara 2.1.4 from http://community.igniterealtime.org/message/233221#233221

And following settings:

Persistence roster - YES, Only internal MUC - NO, Do not add sudomains - NO, Support jabber:iq:registered - YES, jabber:iq:last - YES, Presence pushing - NO, Gajim - NO.

Do clients have to send the presence also the all registered components?

Yes, but Openfire + Spark implements own non-standard logic to track components registration

Is there any reason why 2.1.4 isn’t found by openfire automatically? I am also unable to locate the code for the 2.1.4 version. The version in Openfires SVN seems to be at 2.1.3: http://fisheye.igniterealtime.org/browse/openfire/trunk/src/plugins/gojara/plugi n.xml?r=13733

Do you have a reference where a RFC or XEP defines that clients have to push the presence to the transports? If this is a bug in gajim, then it should get reported as such.

You currently can find compiled Versions of Gojara here: http://community.igniterealtime.org/thread/51137.

Code is now updated to 2.1.5 in SVN.

In this specification, the primary Use Case for login is triggered by the server (after receiving initial presence): http://xmpp.org/extensions/xep-0100.html#usecases-jabber-login

I don’t think Gajim does anything wrong as xmpp-client - it is quite obvious that the server should handle pushing all presences to all roster contacts. For functionality like you described (“having different statuses for different gateways” this is problematic though - because the roster also includes gateway items. If the server broadcasts to these, you once again have only one status. There is probably work to be done on both sides: dont allow server to broadcast to gateway items & send directed presences to gateway contacts from client.


If you **do not **use Spark with Gojara and don’t have requirements like us you should probably have the following minimum configuration (2.1.5):

Enable persistent Roster - CHECKED

Do not add Subdomains to roster - UNCHECKED

Block presence pushing to rosterItems except gateway - UNCHECKED

To be safe you can restart Gojara after these changes (Plugins -> Restart)**

Spark wants to provide additional behaviour by making it possible to decide whether you want to connect to a gateway on startup. If you want to use this behaviour you need to CHECK presence pushing.

I hope this explains some of the situation

Regards, Axel


Some additional thoughts about this presence “Issue”: With gajim you currently should be able to send directed presences to single gateways, which of course are only forwarded and not broadcasted. A broadcasted presence to normal XMPP Contacts however will then get broadcasted to all contacts and overwrite the other statuses - this is something we could prevent with Gojara. BUT it stands in conflict with how gajim currently autoconnects to transports - which is just sending broadcast available, then letting server broadcast to gateway contacts.