On Apr 15, 2009, at 17:32, Lachlan Deck wrote:
On 16/04/2009, at 1:51 AM, Stamenkovic Florijan wrote:
It would also open up a can of worms too. With normal connections
you can get an optimistic locking failure and can present this
immediately to the user. In its absence you'd either not be able to
use any locking at all (and thus the last update wins however old it
may have been queued) or have the user deal with failed updates at
some later date.
Problems:
- will all clients connect again at the same time? No.
- how would you determine the correct order of queued updates being
applied? Can't.
- how would you deal with failures? Is the user still there to deal
with it?
- Do they have to deal with every off-line update manually?
Even if it became read-only when the connection dropped you'd still
have to send all changes simultaneously to the client cached db and
the remote. I'm replicating data between clients and their web site.
I can guarantee this won't be fun to implement nor be out of your
hair in six months.
Yes, I see what you're saying. Managing update conflicts might be a
killer. I originally thought of this in terms of replicating data from
one persistence system to the other, didn't even consider using this
in a full blown multi-user, concurrent-update scenario. But when John
posted his question, I thought: "hey, that idea I had could handle
this!" I guess I have a tendency to run my big mouth before thinking
something through... In my defense, I put some qualification in my
original reply, I said:
"The only problem is: while this *might* be possible, I bet that to
bring it to a functional, usable implementation, it would take (me,
alone) at least half a year of focused work."
;)
F
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
