On 29 November 2010 10:27, Torben Weis <[email protected]> wrote:
> 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. > This is a difficult problem but I don't think we need to arrive at a good solution immediately. Something like (c), perhaps without the rewind, is a reasonable start. This will be a very infrequent occurrence. If deltas are rejected due to permission failure just freeze the panel so the user can't keep typing, and tell them what happened. Give them the opportunity to copy/paste their fresh content if they want before closing the wave, but then they're done. Basically, I don't think this needs to be solved at the protocol level. It's an application problem. > > 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]<wave-protocol%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > -- 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.
