[news.eclipse.technology.riena] Re: Online/Offline Synchronization Workf

[Alexander Ziegler <alexander.ziegler@xxxxxxxxxxxx>]

Hi Tom


On 14.04.2008 11:11 Uhr, in article ftv73g$qb6$1@xxxxxxxxxxxxxxxxx, "Tom
Seidel" <tom.seidel@xxxxxxxxxxxxx> wrote:

> Alexander,
> 
> You're right. Synchronization of data can become very complex. But is
> this within the scope of Riena? - I think not, because calculating
> deltas is application specific and is not implemented in an
> online/offline service. I think the service should have only the
> capability to delegate such synchronization requests.
Yes, I also think that a Framework should only provides the mechanism to
handle and sends data. Calcualting could become very complex and it is
better handled by the application. Currently it isnt in the scope. But I
think it is something which fits very well into Riena :-).

> I just was wondering if Riena would be a good place to provide services
> which support a sequence of service requests where a caching or
> synchronization can be implemented. Especially while working with
> complex data it is necessary to provide some more intelligent workflows
> than requesting and locking the online data.
I agree. However I try to separate the needs of caching/synchronization and
offline/handling/checkout/checkin

> Locking & Editing data is IMHO application specific and should be
> implemented individually. I also have taken a look to the Team-Framework
> which provides similar framework-structures but I came to the conclusion
> that it is not very lightweight and not suitable for a synchronization
> of "real" dataobjects.
Yep for Locking & Editing data.

> 
> Cheerz
> Tom

Best wishez
Alexander
> 
> 
> Alexander Ziegler schrieb:
>> Tom,
>> 
>> I understand your scenario more like a client side caching mechanism (I
>> wrote some comments before to ekkes post). I think such mechanism/framework
>> is very interesting for us for such use cases that the client can work
>> always with a newest version of some data.
>> 
>> I think in a real offline scenario this mechanism isnt enough. Because,
>> process offline work often needs very complex data depends on the
>> application use cases. I have a real scenario with many use cases that needs
>> implicit 80 percent of the whole domain objects offline. In this case I
>> think we need a special service which checkout all the required data to the
>> client at one time. And couple of days later upload/checkin the modified
>> (maybe only the deltas) back to the server. This sync in my scenario would
>> be handled on the server maybe through the application itself.
>> 
>> What do you think of to different mechanisms/frameworks for smart caching
>> and real offline context?
>> 
>> Alexander
>> 
>> 
>> 
>> 
>> On 11.04.2008 13:38 Uhr, in article ftnijj$p1r$1@xxxxxxxxxxxxxxxxx, "Tom
>> Seidel" <tom.seidel@xxxxxxxxxxxxx> wrote:
>> 
>>> Christian,
>>> 
>>> My intension was more to provide a framework for such things, not an API
>>> for merging objects. My thoughts are:
>>> 
>>> 
>>> As an adaptor I don't want to care about when thing are executed, I just
>>> want to implement something like that
>>> 
>>> SyncSession sync = new SyncSession(IUserService.class);
>>> sync.setElementVersionComparator(myElementComparatorWhichImplementsAVersionC
>>> om
>>> parison);
>>> sync.setSyncStrategyImpementation(myImplementationWhichControlsInWhichWaysTo
>>> Sy
>>> nchronize);
>>> sync.addMergeListener(myMergeListenerThatRefreshsMyView)
>>> IUser user = ((IUserService)sync.getService()).findUserById(myId);
>>> 
>>> 
>>> Under the hood the SyncSession is aware of the Online and Offline
>>> Service, asks the higher ranked service (offline-service) and returns
>>> the result. Asynchrounisly it asks also the online service with the
>>> version-number of the result-object if this service can provide a
>>> newer-object (the service-interface has defined a method like Object
>>> getVersion(). This result is passed to "myElementComparator..." which
>>> decides if the online object must be transferred to the client. If so,
>>> the online-service is called and the result will be processed in
>>> "myImplementationWhichControlsInWhich...", where the offline object will
>>> be replaced if it is not locked (the object must implement ILockable).
>>> After the replacing procedure all listeneres that are registered on my
>>> SyncSession will be notified with the change. So I can attach e.g. a
>>> TableViewer as a listener that refreshs the old local object with the
>>> new (or highlights or whatever)...
>>> 
>>> Any comments? ;)
>>> 
>>> Tom
>>> 
>>> Don't care about the names in my Snippet.
>>> 
>>> 
>>> Christian Campo schrieb:
>>>> Hi Filippo,
>>>> 
>>>> I agree that this wouldnt and shouldnt be a decision the user makes. The
>>>> proposed service would just cache
>>>> results that it last received when it was online. Currently we are
>>>> talking about data that does not need to be
>>>> updated at least that is how I understood ekke.
>>>> 
>>>> What do you think ? Could that be a starting point ?
>>>> 
>>>> Why do you think that optimistic locking is a showstopper ? I thought it
>>>> is the solution for sending update without keeping a lock in the database.
>>>> 
>>>> I think what users do understand is a checkout / checkin mechanism. So
>>>> you could checkout say a customer record. Maybe you mark it as such in
>>>> the central database. Then later after you have done modifications you
>>>> check it in. Now if get into a collision that will get tricky I agree on
>>>> that one. Have you ever tried to implement that ? Did you get many
>>>> collisions because I think if it works most of the times its still a
>>>> benefit for the user. And you could still somehow lock the entry in the
>>>> central database so that noone else modifies it in the meantime.
>>>> 
>>>> cheers
>>>> christian
>>>> 
>>>> Filippo Carone schrieb:
>>>>> ekke ha scritto:
>>>>>> but for the online/offline sync this will be no solution.
>>>>>> I would look to find a good sync-service-solution and then try
>>>>>> to integrate this with Riena
>>>>> I guess there's no general solution to this problem. Everytime we
>>>>> tried to implement this concept in our client/server app, we entered
>>>>> in a world of pain. In our experience the users are not accustomed to
>>>>> think online/offline mode and in general would not know how to correct
>>>>> eventual conflicts during a merge (in svn terms of merge and conflict).
>>>>> 
>>>>> I also see optimistic locking to be a showstopper here.
>>>>> 
>>>>> Anyway, has anyone taken a closer look at google gears to see how it
>>>>> makes it possible to run the app while offline?
>>>>> 
>>>>> Cheers,
>>>>> Filippo
>>