[Kolab-devel] zpush: name of the annotation

Bernhard Reiter bernhard at intevation.de
Fri Mar 26 21:18:46 CET 2010


On Thursday 25 March 2010 18:51:08 Georg C. F. Greve wrote:
> On Thursday 25 March 2010 18:21:00 Bernhard Reiter wrote:
> > You did agree to the notion before that the default cannot be YES:
>
> You misunderstood what was written.
>
> That was about shared folders, not a users' own folders.

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.

> > Then we can do it the other ways around:
> > Existance of the annotation means: The folder can get synced,
> > unless the device is listed as explicit value.
> > [...]
>
> This is getting more and more complicated, and for no obvious reason.

I have the opposite impression and I am trying to understand what is going on.

> I would suggest to stick with the simple approach that was suggested by
> Alain: A private (so user specific) annotation per folder that can carry
>
>         (a) the default value for this folder
>         (b) deviations for the default for this folder by phone
>
> If the annotation does not exist, the default is YES for folders in the
> namespace of the user (INBOX/*) and NO for all other folders.

Overall I think it is more simple to have one rule for each folder
and do not depend on if the folder is part of the inbox or not.
(This is not easy to determine on some IMAP layouts, btw.)

You are saying that people will want to have a sync by default, but for 
security reasons that is not possible for all folders as we have established.
So I am proposing a scheme which keeps one rule for all folders
which includes on activation mechanism with a real Kolab Client, e.g the web 
client. Otherwise I believe quite a few people will miss their events from 
other folders.

> If a device needs special settings, that can be defined as part of the
> device specific settings. Administration will take place over the web admin
> interface by default, Gunnar already said that this kind of structure would
> be easy to implement - in the area of one day.

There is just one potential setting we were talking about: 
hierarchical or flat syn mode.
And this is not per folder, but per device.
So it should not be in every folder otherwise you get a conflict if folder A 
says hierarchical and folder B says flat.

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.

> The only open question is where we get the device serial number from for
> the configuration, as we do not want the user to have to enter this - in
> fact we would prefer to have a better representation of the phone than its
> serial number in the user interface, if possible.

The suggestion of the activation mode might possibly solve this for good
as well. I think of the following steps:
a) enter the right URL and setting in your phone, try to sync
b) zpush does not have any folder with the annotation thus, it will syn back 
with a welcome event or task or contact: saying: please activate your folder 
on url demo.kolab.org/activatezpush. But zpush temporarily remembers the phone 
data.

c) User goes there, get presented a selection of phones that have tried to 
sync in the past (and had the credentials).And of course all folder where 
there is access. User can now initiative the sync, which will write the 
annotation

d) next phone just syncs like the first phone by default. zpush again 
remembers the phone data.

e) User can go to the client to adjust the folder and now has the selection of 
phones,  can be disabled for folders that have been enabled before.

Best,
Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Germany Coordinator: fsfeurope.org. Coordinator: Kolab-Konsortium.com.
Intevation GmbH, Neuer Graben 17, Osnabrück, DE; AG Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner




More information about the devel mailing list