Re: [Sync4j-users] DeletedSyncItems, Twin and Conflict

[Stefano F. <ste...@fu...>]

Hi Harries,

> 
> In my opinion the problem is that the MemorySyncSource does not
> create SyncItem related to a SyncSource. The part 
> 'syncItemKey.equals(all[i].getKey())' is with differen SyncItems
> quite useless. The more most of the system compares items in a binary
> form. (This may be due to the way I use Sync4j is quit different
> then many. I am attempting to synchornise phones with a calendar server
> where I have a different (more complete) set of properties per item.

this point is arguable. When you have the mapping, comparing the entire 
content body is a waste of time and resources. It is not at this level 
that you have to look into the content. If you have the mapping, the ids 
are all what you need to know, because that equality test has to 
discover if the client or the server is doing anything with items you 
know already about.

> 
> Last week I already provided a patch/contrib related to this. This
> contrib added a SyncItemFactory per SyncSource and at the creation
> of the MemorySyncSource a SyncItemFactory producing equal SyncItems
> as the backend was set up.
I am not a factory lover, since factories most of the times give you 
little abstraction (and then benefit) with more complexity and then 
loosing understandability. I may argue: think about the MemorySyncSource 
  alone... it represents a SyncSource in all its aspect: why should it 
have knowlodge about to which source an item is bound in the server? 
This approach will mix two different concerns: the representation of a 
data items manager with the details about how a data source is kept in 
the server. I do not like it too much. If the MemorySyncSource does not 
need to know about how an Item is stored, then it is better (IMHO) just 
not to add that knoledge.

> 
> As Stefano suggested, you can use the getSyncItemsFromTwin
> functionality, but that looks limited and trying to work
> around the issue to me.
This is probably the point that drove your statement above. Actually the 
getSyncItemsFromTwin is not a workaround at all. It is the way you make 
items comparison for equality. This is an important point, and I think 
it is good that this is delegated to the SyncSource: in one single place 
you put the logic to access data. Looking for equal items (whatever this 
means for a SyncSource) requires exactly to query the datastore as a 
getModifiedSyncItems.

Of course, this is open to discussions.

Stefano
--------------------------------------------------------------

    FAQ:
    http://forge.objectweb.org/docman/view.php/96/39/general.html
    Project Documentation:
    http://forge.objectweb.org/docman/index.php?group_id=96
    Documentation site:
    http://sync4j.funambol.com/main.jsp?main=documentation
    List archives:
    http://groups.yahoo.com/group/Sync4j (login required)
    http://sourceforge.net/mailarchive/forum.php?forum_id=215

    --
    Stefano Fornari                   stefano.fornari@fu...
    Funambol CTO                      http://www.funambol.com

    6472 Camden Ave #106              Via dei Valtorta 21
    San Jose, CA 95120 (USA)          20127 Milano (Italy)
    Tel.: +1 408 705 2044             Tel.: +39 02 2614 5383
    Fax: +1 408 705 2044              Fax: +39 02 7005 60230

                 Your Mobile Application Platform