On 3 December 2010 12:34, Torben Weis <[email protected]> wrote: > >>> 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. >> > > As long as the user is working online there is no real problem with > freezing the wave panel because the user gets almost immediate feedback. > Should we ever support real offline work, i.e. allow for deltas to be stored > in a HTML5 store, then the damage caused by such an incident can be high > (stored deltas are lost because a delta in front of them had a problem) and > fixing it is difficult. >
I'm not suggesting losing any data. A user can be offline for a day, write lots of stuff, come back to have their first op rejected and then the wave panel freezes. All their text is still there. They can copy/paste. Maybe we add a "copy to new wave" button. I'm obviously glossing over many details that need thinking about, but we should be able to build the application to do something helpful when a whole lot of content is rejected. Note that this behaviour may be desirable even when there are no permissions errors. If a user comes back online and has a huge diff with other changes that happened concurrently, waves OT may not do what is desired. In some cases it may be a better user experience to perform a manual merge. >> Basically, I don't think this needs to be solved at the protocol level. >> It's an application problem. >> > > I do not believe that missing error semantics and missing error codes are > an application problem. The protocol must at least state what kind of error > this was. > Sorry, I didn't mean the protocol shouldn't specify the kind of error, but to a large extent I don't imagine the application response would differ much. But if a user has lost access then the protocol can't do much to help them. For example, it would be ridiculous for the protocol to decide to move all the user's rejected deltas into a private reply wavelet in the same conversation. That amount of smarts and complexity and application-specific logic in the protocol will lead to unmanageable complexity. But the application can do something sensible, like asking the user. > Torben > > >> >>> >>> 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]<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.
