[Kolab-devel] Z-push optimization

[Bernhard Reiter]

Am Freitag, 1. Oktober 2010 13:36:04 schrieb Alain Abbas:
> Each time that a mobile synchronize i must read all the annotations of
> all the folders to know if a folder is for sync or not
> i ve got some customers with big trees ( arround 300 folders in Inbox)
> become a bottleneck.
>
> 1) how to do not read at each time all the annotation folders ?
> even if i cache some informations that become the hell
> and i must know if the annotations are changed or not
> to put or remove the folder to the sync

A simple measure would be to create a fast and a full sync
for your client. (Technically your solution should be a client
to the core server. Of course it will be installed on all Kolab Servers.)

The fast sync will just work on the cached folder types and only
sync the folders that are interesting. So the information you want to
consider is significantly less.

And the full sync will check all folders and thus detect new ones
and their annotations. The question then is: when to do the full sync?
You could either make the full sync every X syncs or every Y hours
and you could add a trigger, e.g. by https. 
Changes to the annotations should be rare and if a client can do them,
it should be easy to just add another https trigger after a change.
So you would shift the time of checking the annotations mainly to every Z 
rounds and a trigger shortcut.


> I thought to make that ,to make a special flag in the INBOX annotation a
> counter :
> If the user modify the annotation of one folder this number could be
> incremented
>
> STEPS :
> 1 when the user modify  an annotation  the  "ANNOVERSION"  is
> incremented in the INBOX folder
> Zpush would check this ANNOVERSION and compare with the old one
> if ANNOVERSION is not equal Zpush read again the annotations
>
> Stay now the problem of the user space where to put this ANNOVERSION ?

I do not think this would work as the trigger would need to be pulled
by all writer to a folder that is relevant. Assume user A gets write access to 
a calender from user B. Then B can change the annotation, but cannot write
A's INBOX.

> I think at this step we see the limitation for this method (annotations
> per folder) and a simple
> list in LDAP should be
> more efficient and simple .

Using the directory server for simple client configuration data is not a good 
idea in my view. In many environments, clients are not able to change the 
data in there easily. Also it would require adding LDAP write support to all 
clients, which I would like to avoid. (There are more drawbacks as far as I 
remember as well.)

Best,
Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/devel/attachments/20101013/6ad48740/attachment.sig>