2010/12/3 Alex North <[email protected]> > 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. >
Building a UI that shows which deltas (i.e. edits/content) had been rejected and offering a semi-manual merge is for sure an interesting UI challenge. Kai wrote in another mail that he is thinking in this direction. > > >>> 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. > Seems we misunderstood each other slightly. I am objecting against the current error reporting in the wave protocol which features only a string but no error codes and no precise error semantics. Of course I do not want the federation protocol to create private replies and stuff. That is application level. Greetings Torben > > >> 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]<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.
