While I think that the group control categories are useful, I am not
sure that they will lead to wide adoption. Wave seems to do best when
it enables rapid and open collaboration. So however these attributes
are exposed must be easily understood and not face users with too many
decisions or confusion about roles. Thought for a possible solution:
1. By default, a message is locked until it is first saved ("Done"/
Shift+ENTER). This would push out a semaphore value to other displays
of the message that would not be cleared until the "transmission" was
cleared.
2. Prior to an initial save, the message creator, may reset perms for
a group or individual to lock a specific message. Default is to open
the saved message to anyone with write perms.
3. The message creator or a Manager+ member may subsequently lock a
message. When they do, in-flight updates from others will be rejected
in the saved version of the message. It will be assumed that such
relocking will be in response to changing circumstances that require
reassertion of control. Main problem may come when two or more people
with authority to lock try to do so simultaneously. Presumably the
"first-in" locker causes all other modifications to the message to be
rejected.
Just a thought.
On Nov 29, 10:27 am, 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.
>
> 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%2bunsubscr...@goog
> > legroups.com>
> > .
>
> > 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.
