2010/11/28 Tad Glines <[email protected]> > On Sat, Nov 27, 2010 at 9:15 PM, dougx <[email protected]> wrote: > >> I think the tricker side of things would be to make the server reject >> document modify events that don't comply to the lock settings of the >> document; and gracefully handle federated updated from clients that >> (for example) don't honor locking... >> > > Every client should properly handle the case where a submit request is > rejected by the server. And the error message returned by the server should > make a distinction between the case where delta application failed and delta > application was denied so that the client can properly report the situation > to the user. >
I fear it is not so easy on the client side, because a client can do everything right (i.e. edit a blip) and concurrently this blip becomes locked by its owner. The client receives an error message although it did not do anything wrong, The first thing required is an error code that tells what happend. Currently there is only a string. But far more complicated is the following: The client may have queued further deltas. If the in-flight delta is rejected, how to transform the consecutive queued deltas? My guess is that no client currently handles this in a reasonable way and therefore this is a rather major change. Currently we have three classes of errors a) Transport. Solution: try again b) Request is somehow malformed -> client is buggy. Solution: give up, send a bug report to the developer c) Permission denied -> user is (no longer?) allowed to change the wavelet. Solution: drop the delta and all consecutive queued deltas. Rewind the UI. If a client sends a delta for a locked blip that has not been locked when the client created the delta, then we have a new error case. Of course we could go with c) and rewind. But imagine a user worked offline, did tons of changes resulting in a set of queued deltas. The first delta yields this new kind of error and all the work done offline is suddenly reverted and gone. Not very nice! This is definitely not as easy as it seems on first glance. Torben > Implementation in the server shouldn't be that complicated. > > -Tad > > -- > You received this message because you are subscribed to the Google Groups > "Wave Protocol" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<wave-protocol%[email protected]> > . > > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > -- --------------------------- Prof. Torben Weis Universitaet Duisburg-Essen [email protected] -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
