[Kolab-devel] zpush: name of the annotation

[Georg C. F. Greve]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/devel/attachments/20100326/ced1afe2/attachment.sig>