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(myElementComparatorWhichImplementsAVersionCom
parison);
sync.setSyncStrategyImpementation(myImplementationWhichControlsInWhichWaysToSy
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