Hello again everyone,
I have some questions concerning dispatch.c, but first a short recap of
the plugin I'm working on :
- the plugin replaces "roster" and allows to write custom sql requests
for accessing data (instead of the storage component). The purpose is to
be able to use our already-existing buddies database, read-and-write.
- I enabled <auto-create/> : the server's other tables (active,
logout...) get populated at the user's first connection
The problem is :
- When an user connects to jabberd2 for the first time, the
active,logout... tables are empty, and the roster is already filled.
- The code in dispatch.c : 130 states that "if one of the user_load
module fails, an unsuscribed-packet will be sent", presumably to clean
the user's rosters on every session by removing this "unknown contact".
- In my case, when an user connects but one of his buddies has never
been connected yet, the "active" module fails to user_load. The
unsuscribed packet is generated, and the buddy-relationship is erased
from the roster, unfortunately losing the relationship.
I see three solutions here :
- using the template-roster module, or adapting it, i could maybe
recreate the buddies-relationships after they are deleted. But it would
mean i have to keep two tables : roster-before-first-connection, and
roster-after-first-connexion(=real roster), which seems weird. Also, it
would mean a lot of unneeded operations on first connection.
- populate all the tables of the server (active, status...) in advance
(i.e before the first connection to XMPP is even possible). It makes
more sense, because it avoid to have "half-created" sessions (with only
a valid roster but nothing else). But it's also a certain amount of work
for me, and server load on the future (to keep every table of the SM's
database up-to-date regarding account creations).
- add a config flag in sm : "allow relationship to not-yet-existing
buddies" that would prevent the "unsuscribed" packet form being sent.
I think the most sensible way is the last one, but I may miss some
issues. Any insight would be greatly welcome, as usual.
Thanks for reading me, and in advance for any answer ^_^.
Le 17/01/2014 11:59, Sylvain Guglielmi a écrit :
Le 10/01/2014 18:23, Tomasz Sterna a écrit
You could have a separate "cron" component pinging 'sm' in regular
intervals with special route packet, and handle this special packet in
'in-router' chain of your module.
Having that it could even be done not in regular intervals, but
on-demand, when your component gets triggered by web frontend.
This works very well ! Thanks for the advice. My "cron" component is a
short php script.
I was unsure about how to answer "disco#info" queries that I get from
other components, but it seems to work without answering anything.
I'll read the "XEP-0030 : Service Discovery" RFC later and try to make
a more compliant "cron" component.
If anyone is interested in the php simple DIGEST-MD5 auth, code can be
found here (It's not robust and exhaustive, but it can be useful I
guess) :
https://github.com/Gugli/jabberd2/blob/master/tools/sendupdatepacket.php
I've been scratching my head for the last couple of days on another
issue : our legacy contact system does not allow asymetrical
relationships (as XMPP does). It would be very complicated to change
that to a more "XMPP-compliant" system. The solution I came up with is
to make a symmetrical mode for my roster module.
In this mode :
- whenever a user sends a presence subscription, the sm also consider
the user allows subscription to the same contact.
- whenever a user allows a contact to subscribe to his presence, the
sm also consider that the user subscribe back to the same contact's
presence.
The session that requests the change has to be informed of this
additional change with a push as any other session. Basically,
item->from and item->to are linked, they always are the same value.
This makes a kind of "restricted XMPP" protocol. It's not great, but
it's the only sensible way I found to go on. Has anyone already done
something approaching ? Is it "bad" ?
Thanks very much again for all the help you provide :)
--
Sylvain "Gugli" Guglielmi
--
Sylvain "Gugli" Guglielmi
