Dnia 2014-01-06, pon o godzinie 18:07 +0100, Sylvain Guglielmi pisze:
> Hello everyone,
>
> To use jabberd2 with my pre-existing contacts database, I started
> writing a roster module with customisable MySQL requests (I mailed this
> list a while back about it, but I just started actual work). It uses
> prepared statements, and config file looks like :
This is really interesting. :-D
It could really accelerate "XMPP as the next social media protocol". :-)
Could you consider using libdbi instead of hardwiring to MySQL?
This would make your implementation more reusable.
> - In order to make simpler custom databases, I wanted to remove the
> "pkt->type == pkt_S10N_UN" / "item->ask == 2" mechanism. According to a
> comment "there is no ask='unsubscribe' in RFC bis anymore ". Would
> anyone advise against it ?
How would that make schema simpler?
You still need to store ask='subscribe', don't you?
> - something that seems weird to me : I was expecting item->ver to be
> incremented each time the item is updated (for example in
> _roster_save_item),
> but couldn't find such code. It there something I don't grasp ?
Ahhh... Yes... There's a little trick I used there. ;-)
ver is coming from auto-incrementing field "object-sequence".
As storage never issues UPDATE but always DELETE first then INSERT,
every updated roster item automagically gets new ver value.
> [...] I thought it would be good to do the same
> thing in the regular roster, but I couldn't find a way to remove a
> specific os_object_t. Is there a way to do that ?
storage_delete() with proper filter.
> Anyway here's what the code could look like, with TODOs :
The clean separation between stanza parsing to roster-item and
roster-group structures which are then stored to DB, and in reverse
makes the code more comprehensible.
I doubt that trading readability for efficiency is worthy in case of
today's microprocessor speeds and RAM availability.
Also, does your use-case covers users in many-many groups?
My experience shows that most users are in 0 groups, some in 1 group and
very few in 2+ groups. There's not many INSERTs to gain there.
Remember: "Premature optimization is the root of all evil."
I would rather suggest adding 'dirty' flag, risen whenever group
membership actually changes. This would keep the separation still,
allowing for bulk drops of unneeded DELETE/INSERTs.
--
Tomasz Sterna :(){ :|:&};:
Instant Messaging Consultant Open Source Developer
http://abadcafe.pl/ http://www.xiaoka.com/portfolio
