SyncML and one way syncs

[Patrick_Bihan-Faou-3]

Hi,

While not terribly active on the various mailing lists, I am still
actively working on refactoring the SyncML code in egroupware. I am at a
point where I’d like to implement the one way syncs from the client to
egroupware. However this needs a bit of thoughts on how to handle them
properly.

There are 2 main cases:

• refresh/initial syncs from the client to egw
• updates from the client to egw

The initial/refresh syncs are of particular interest as they are
supposed to cause a DB cleanup on the server side initially. Of course
this does not work well with systems where data (such as contacts etc.)
may be shared and owned by different users.

What I am asking today is if some of you have ideas on how such things
should be handled and what the expected behaviour should be.

Lastly, I have a significant amount of changes in the syncml code right
now locally on my machines, however it is not quite ready for prime time
yet. Since I am doing that in my spare time, please be patient! Rest
assured that all my work will be commited to egroupware when ready.

Patrick.

---

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft® Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

[Aleksander_Adamowsk2]

The initial/refresh syncs are of particular interest as they are
supposed to cause a DB cleanup on the server side initially. Of course
this does not work well with systems where data (such as contacts etc.)
may be shared and owned by different users.

What I am asking today is if some of you have ideas on how such things
should be handled and what the expected behaviour should be.

I thinke the most reasonable logic initially woule be to only consider
contacts the user is the owner/creator of.

For calendar and Infolog items thins get more complex, especially WRT
invitations.

If a user gets invited to a meeting, this should definitely get synced
down to his device, even if he didn’t accept the meeting yet. However,
there’s a list of invited people over there, most/all people likely
wouldn’t be in the personal address book (as the users of the same
eGroupWare system they would be in the “accounts” address book, which
isn’t synced).
I’m not knowledgeable enough in the area of SyncML to propose a
solution, I can only see that this will definitely become a problem
(probably a difficult one).

–
Best Regards,
Aleksander Adamowski
http://olo.org.pl

---

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft® Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

[Ralf_Becker_6]

Hi Patrick

Aleksander Adamowski schrieb:

The initial/refresh syncs are of particular interest as they are
supposed to cause a DB cleanup on the server side initially. Of course
this does not work well with systems where data (such as contacts etc.)
may be shared and owned by different users.

What I am asking today is if some of you have ideas on how such things
should be handled and what the expected behaviour should be.

I thinke the most reasonable logic initially woule be to only consider
contacts the user is the owner/creator of.

Why not simply use the current ACL: if the user has the right to delete
and entry, it get deleted in the initial one-way-sync. If he has no
rights to do that, you have to ignore it.

For calendar and Infolog items thins get more complex, especially WRT
invitations.

I think a delete of an (only) invited user should be treated as
rejection of the meeting. That should work well, as rejected meetings
can be disabled from being returned by bocal::search(), so it would work
like a delete.

If a user gets invited to a meeting, this should definitely get synced
down to his device, even if he didn’t accept the meeting yet. However,
there’s a list of invited people over there, most/all people likely
wouldn’t be in the personal address book (as the users of the same
eGroupWare system they would be in the “accounts” address book, which
isn’t synced).

I think the only solution for that is, to allow a further type of
participant (beside accounts and contacts), which is only identified by
it’s mail address. That means this mail address needs to get stored in
egw_cal_user AND need to be part of the primary key their.

We also need that non-contact participant for iCalServer, GroupDAV and
CalDAV.

Ralf

Ralf Becker
eGroupWare Training & Support ==> http://www.egroupware-support.de
Outdoor Unlimited Training GmbH [www.outdoor-training.de]
Handelsregister HRB Kaiserslautern 3587
Geschäftsführer Birgit und Ralf Becker
Leibnizstr. 17, 67663 Kaiserslautern, Germany
Telefon +49 (0)631 31657-0

---

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft® Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

[Aleksander_Adamowsk2]

Why not simply use the current ACL: if the user has the right to delete
and entry, it get deleted in the initial one-way-sync. If he has no
rights to do that, you have to ignore it.

In order to avoid spamming the mobile device with insane amounts of
contacts a user doesn’t need or want.

Imagine an eGroupWare installation for 10000 users. Syncing the
"accounts" address book will probably fill up almost any mobile device
so it won’t accept any more.

The same goes for an installation where there are numerous customer
contacts shared from coworkers. When they gon into thousands, I expect
some mobile devices to fail on that. The user doesn’t have control
over how many contacts are shared with him. But he has control over
the number of contacts he owns.

If a user gets invited to a meeting, this should definitely get synced
down to his device, even if he didn’t accept the meeting yet. However,
there’s a list of invited people over there, most/all people likely
wouldn’t be in the personal address book (as the users of the same
eGroupWare system they would be in the “accounts” address book, which
isn’t synced).

I think the only solution for that is, to allow a further type of
participant (beside accounts and contacts), which is only identified by
it’s mail address. That means this mail address needs to get stored in
egw_cal_user AND need to be part of the primary key their.

We also need that non-contact participant for iCalServer, GroupDAV and
CalDAV.

Yes, such functionality will be inevitably required. I always wondered
what currently happens to meeting participants when meetings are sent
through iCal or SyncML?

–
Best Regards,
Aleksander Adamowski
http://olo.org.pl

---

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft® Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

[Ralf_Becker_6]

Hi Aleksander,

Aleksander Adamowski schrieb:

Why not simply use the current ACL: if the user has the right to delete
and entry, it get deleted in the initial one-way-sync. If he has no
rights to do that, you have to ignore it.

In order to avoid spamming the mobile device with insane amounts of
contacts a user doesn’t need or want.

Imagine an eGroupWare installation for 10000 users. Syncing the
"accounts" address book will probably fill up almost any mobile device
so it won’t accept any more.

The same goes for an installation where there are numerous customer
contacts shared from coworkers. When they gon into thousands, I expect
some mobile devices to fail on that. The user doesn’t have control
over how many contacts are shared with him. But he has control over
the number of contacts he owns.

That’s a completly different topic. We need a way a user can specify,
which contacts (from the ones he has access too), he wants to sync on
his mobile, eg. everything containing the category “mobile” or
"customers", plus the personal addressbook, or a certain distribution list.

Ralf

If a user gets invited to a meeting, this should definitely get synced
down to his device, even if he didn’t accept the meeting yet. However,
there’s a list of invited people over there, most/all people likely
wouldn’t be in the personal address book (as the users of the same
eGroupWare system they would be in the “accounts” address book, which
isn’t synced).

I think the only solution for that is, to allow a further type of
participant (beside accounts and contacts), which is only identified by
it’s mail address. That means this mail address needs to get stored in
egw_cal_user AND need to be part of the primary key their.

We also need that non-contact participant for iCalServer, GroupDAV and
CalDAV.

Yes, such functionality will be inevitably required. I always wondered
what currently happens to meeting participants when meetings are sent
through iCal or SyncML?

–
Ralf Becker
eGroupWare Training & Support ==> http://www.egroupware-support.de
Outdoor Unlimited Training GmbH [www.outdoor-training.de]
Handelsregister HRB Kaiserslautern 3587
Geschäftsführer Birgit und Ralf Becker
Leibnizstr. 17, 67663 Kaiserslautern, Germany
Telefon +49 (0)631 31657-0

---

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft® Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers