[Kolab-devel] zpush: name of the annotation

[Alain Abbas]

hi
completely agree with you georg
we must see what want the magority of users:
my feel
95% of user want their contacts and calendars . i think those users  
woll never connect on the admin interface because they would have that  
they want

few % woulld wants shared address book
and very few other users calendars ( otjers users calendars would not  
very lisible from the flatmode)
with the case that i described we cover that

about flat or folder mode
i resolved the pb with detecting the type of the device who sync
i introduced a new define in the config file.
KOLAB_MODE
0 flatmode
1 foldermode
2 automatic
for the moment just iphone can handle the foldermode
i keep in each sync the mobiletype and the user agent who represent  
the type + the version
with that easy to choose the mode
i will make a config file to put inside with type witch mode for the  
future.

now if one user want to be in flatmode with a phone who handle  
foldermode ( the other wy has no sense)
we could put an annotation in the main inbox( because i must know the  
mode before to retrieve the folder list)

now about annotation
i read again all the posts about that an found a lot of "should work"  
and few "will work"
i want to reopen this talk because im sure that ldap can handle and  
that ther e are too questions without responses about annotation.

on LDAP with simply an auxiliary class we CAN store those parameters  
easly
1) easy to change the admin interface
2) no write rights pbs
3) this is just read very few rights
4) just one search at the login in the other case imap we must read  
the annotation at each folders , what about 2000 users ?
i know we will not have bottlenecks with LDAP

we are used to use Ldap and add some schemas in kolab to use it with  
samba or sympa or other softs and really i don t see whitch problems  
we could have.
we have lot of kolab install with a modified schemas to store  
differents metadatas without problems

the only diff with others kolab install i think that we don t store  
users in a flat tree but in a real ldap tree and we administrate it  
with our proper interface


i will push the release test monday morning with all the feature of  
the m1

Alain


Le 26 mars 2010 à 22:53, "Georg C. F. Greve" <greve at kolabsys.com> a  
écrit :

> On Friday 26 March 2010 21:18:46 Bernhard Reiter wrote:
>> Well, if those folder contain calender data that the users needs on  
>> a daily
>> basis, this user will miss them on the default sync as well.
>
> If they have a more complex setup, then yes.
>
> But for most people, their personal calendar is the most important and
> essential calendar they have - and the one that they almost  
> certainly will
> want synchronised.
>
> Building a more complicated solution that matches 0% of all user's
> expectations because the simpler approach would match only 95% of  
> all user's
> expectations seems like a bad tradeoff.
>
>
>> There is just one potential setting we were talking about:
>
> No, this is one of several settings that enter into the whole picture.
>
> There is the setting whether a user can use ActiveSync, at all (in  
> LDAP).
>
> There is the setting for the cut-off date (server default, device  
> modified).
>
> There is the question which folders a user wants synchronised, with  
> the need
> for a default setting, and a need for modification of that default  
> setting (in
> IMAP).
>
> There is the question which device should be in flat mode, and the  
> additional
> question where new events from the device should go WHEN a device is  
> in flat
> mode.
>
> You may be right however that we need another activesync specific  
> setting, so
> not just
>
>    /vendor/type/activesync
>
> but also
>
>    /vendor/type/activesync-devices
>
> in the user's base folder to manage (a) which devices are known to  
> be used by
> a particular user, and (b) which device-specific settings we have  
> (e.g. flat
> mode, and which folder is the target for new items).
>
>
>> You would need to define the precise folder it is in and this has  
>> to exists
>> for stuff to work. A candidate would be the event.default folder.
>> If this is just one setting we are talking about, I think that  
>> using two
>> different URLs could still be an option.
>
> Only that we have no guarantee that any folder has the ".default"  
> annotation.
>
> There are plenty of versions of Kontact around that remove this  
> annotation at
> random, so we'll need to assume that for the next 5 years, we cannot  
> rely on
> this annotation to actually exist.
>
>
>> The suggestion of the activation mode might possibly solve this for  
>> good
>> as well. I think of the following steps: [...]
>> folder on url demo.kolab.org/activatezpush. But zpush temporarily
>> remembers the phone data.
>
> Of course such an intricate scenario could be made to work.
>
> The only problem is that it fragile and the description glosses over  
> the
> actual problem, which has been brought up before with no concrete  
> proposals:
>
> *Where* to remember the phones that a user has tried to connect?
>
> It needs to go where the rest of the configuration system has access  
> to it, so
> either LDAP or IMAP. Putting it somewhere on disk in Z-Push is just  
> not good
> enough.
>
> So which is your proposal? LDAP? IMAP? Where in these two?
>
> And how is this scenario better than:
>
> (a) User enters details in phone, hits sync, gets default data,  
> which is
>    either the Kolab default, configured system wide by the admin, or
>    the modified default by the user, with latter overriding former.
>
>    In this step the server memorizes the phone for this user.
>
> (b) If the phone is a "flat mode" phone, the user will notice that  
> (s)he is
>    missing events/contacts/tasks. When looking into the web interface,
>    there is a help item "What to do if some items are missing?" that
>    explains flat mode and guides the user through activation.
>
> If the phone is a phone that supports multiple folders, step (b)  
> falls away.
>
> Best regards,
> Georg
>
> -- 
> Georg C. F. Greve
> Chief Executive Officer
>
> Kolab Systems AG
> Zürich, Switzerland
>
> e: greve at kolabsys.com
> t: +41 78 904 43 33
> w: http://kolabsys.com
>
> pgp: 86574ACA Georg C. F. Greve
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel