Re: [Phpgroupware-developers] Synchronization support for phpGW - Draft

[Markus Kaemmerer]

"Brian Johnson" <address@hidden> wrote:,

>I'm not certain that Palm OS PDAs use the vcalendar or vcard standards.  That 
>should
>be investigated before making that assumption.

Palm Desktop supports this standard so it may be possible that you can
access this functionallity through a conduit system. If not, there are
comprehensive vCard/v*/i* support libraries available (see link
section in our document). If someone implements SyncML client support
for Palm (which whould allow synchronization with phpGW and Palm) the
vCard/vCalendar support is mantadory wihin the SyncML spezification. 

>Even though most devices will transfer the entire record when a part of it has
>changed (dirty), when you start looking at multi-table relationships like the 
>new
>addressbook, it would be best to check all feilds for dirty and merge together 
>the
>most up-to-date info prior to the device data sync

I made a comment about this topic already in chapter 1.5. If one field
of a record is dirty, we will consider the whole record as dirty. With
the (optonal) implementation of intelligent merging within layer 1
(phpGW module) it may be possible to handle the case of field changes
more sophisticated than with marking the complete record dirty.

>Just to reiterate, there are a couple of coldsync based conduits available for
>review not referenced in your docs: one from me and one from skwashd.  And fixe
>(Axisgroupware) has some phpgw coldsync control modules

We dont want do do a synchronization system which is tied entirly to
coldsync. Coldsync is only one option (with palm on linux the only
one) in the whole system. We want a synchronization system which may
be extended easaly to any other devices, including unknown one. 

>I also have outlined a concept for linux based pdas to use ssh to establish 
>network
>connections, and have the server take over syncing their data files that may 
>be useful

This will not be our problem :). As long the end user devices is
capable of doing SyncML via HTTP, WSP or OBEX (Transport binding
between layer 5 and 6) to our server this devices is able to
synchronize. The device has to autorize with username and password and
may use any sort of secure connection to the server (including common
things like SSH or VPN). 

>A lot of people have been anxiously awaiting a pda sync system.  For my own 
>reasons,
>I hope you start with Palm OS PDAs (after all they are the PDA market leader).

We know that Palm OS synchronization is high on the wish list of many
phpGW users (including myself). In fact the Palm OS support is the
last milestone in our whole project. We do not develop a sync hack for
a special device, we want to develop a whole synchronization framework
with seven mostly indepent layers.

I whould like to encourage everyone to help us with this project. To
add PalmOS synchronization support for phpGW we "only" need an SyncML
Conduit for Palm. Everyone can start _now_ to develop this piece of
software and test it against the Sync4j server (which includes a
comprehensive test suite). If our project goes as we want than we can
do a fulll sync at CeBIT time with any SyncML client - including
PalmOS if the Conduit is ready. 

> I for one think that once the system is set up, required user
>intervention should be minimal for config and that conflict reports should be
>emailed to the user and allow them to resolve the conflicts post sync instead 
>of
>pausing the sync to wait for a resolution.  

There is no config et all. If a conflict can not be solved
automatically it is saved in an internal database (see database
diagram and documentation in the yet to be translated chapter 2.1).
The use may see and resolve the conflicts in the sync module GUI
(layer 3) at any time. With the help of the module integration project
we are working on it wiil be possible to show the user the record of
any supported module side by side to allow a manually conflict
resolve. 

>Also, full category support should be
>provided where the PDAs support categories

This is planned at later stage, because it is more end user device
specific than other things. But we keep this in mind, of course.

Markus