Groups and wavelet permissions

[Tad Glines]

I'm working on adding group support to WiaB and also looking at the issue of
wavelet permissions.

As a starting point I want to propose some group and wavelet roles and
solicit feedback.

For groups the roles I'm proposing are:

- Reader
- May read waves on which the group is a participant.
- Contributor
- Includes Reader capabilities
- May submit deltas to wavelets for which group is a participant. The
delta author must be the submitter.
- Manager
- Includes Contributor capabilities
- May add/remove members to/from the group and modify the role of
existing members, but only if:
- The member is self
- The member is NOT a manager
- The member is NOT an owner
- Owner
- Includes Manager capabilities
- May add/remove members to/from the group and modify the role of
existing members, but only if:
- The member is self
- The member is NOT an owner.

For wavelets the roles I'm proposing are:



- Reader
- May read wavelet content
- Contributor
- Includes Reader capabilities
- May add new wavelet content. In the context of a conversation
wavelet, this implies adding new blips.
- May edit own content. In the context of a conversation this implies
editing or deleting own blips.
- Editor
- Includes Contributor capabilities
- May add/edit/delete any content.
- Manager
- Includes Editor capabilities
- May add/remove participants and modify the roles of any exiting
participant if:
- Participant is self
- Participant is NOT a Manager
- Participant is NOT an Owner
- Owner
- Includes Manager capabilities
- May add/remove participants and modify the roles of any exiting
participant if:
- Participant is self
- Participant is NOT an Owner

For both groups and wavelets the creator would be granted the owner role.

-Tad

[Vega]

That would be really important addition to wiab. By the way, how do
you intend to implement the groups functionality in wiab? Is it
related to google groups?

Post by Tad Glines
I'm working on adding group support to WiaB and also looking at the issue of
wavelet permissions.
As a starting point I want to propose some group and wavelet roles and
solicit feedback.
   - Reader
      - May read waves on which the group is a participant.
   - Contributor
      - Includes Reader capabilities
      - May submit deltas to wavelets for which group is a participant. The
      delta author must be the submitter.
   - Manager
      - Includes Contributor capabilities
      - May add/remove members to/from the group and modify the role of
         - The member is self
         - The member is NOT a manager
         - The member is NOT an owner
      - Owner
      - Includes Manager capabilities
      - May add/remove members to/from the group and modify the role of
         - The member is self
         - The member is NOT an owner.
   - Reader
      - May read wavelet content
   - Contributor
      - Includes Reader capabilities
      - May add new wavelet content. In the context of a conversation
      wavelet, this implies adding new blips.
      - May edit own content. In the context of a conversation this implies
      editing or deleting own blips.
   - Editor
      - Includes Contributor capabilities
      - May add/edit/delete any content.
   - Manager
      - Includes Editor capabilities
      - May add/remove participants and modify the roles of any exiting
         - Participant is self
         - Participant is NOT a Manager
         - Participant is NOT an Owner
      - Owner
      - Includes Manager capabilities
      - May add/remove participants and modify the roles of any exiting
         - Participant is self
         - Participant is NOT an Owner
For both groups and wavelets the creator would be granted the owner role.
-Tad

[Tad Glines]

Post by Vega
That would be really important addition to wiab. By the way, how do
you intend to implement the groups functionality in wiab? Is it
related to google groups?

No it's not related to google groups not is there any plans to use google
groups. At least initially there would be no group federation either. So, a
group would only work within a single server and could only have members
from that server. Once that's working, we can look at the best way to
implement group federation.

-Tad

[Michael MacFadden]

Tad,

Can you expand on exactly what the group functionality is? Is is just
a permissions scheme? Is it a new kind of model element (like a peer
to wavelet). I think the roles you define make sense, but I am
missing the bigger picture of what this functionality is all about.

~Michael

Post by Vega
That would be really important addition to wiab. By the way, how do
you intend to implement the groups functionality in wiab? Is it
related to google groups?

Post by Tad Glines
I'm working on adding group support to WiaB and also looking at the issue of
wavelet permissions.
As a starting point I want to propose some group and wavelet roles and
solicit feedback.
   - Reader
      - May read waves on which the group is a participant.
   - Contributor
      - Includes Reader capabilities
      - May submit deltas to wavelets for which group is a participant. The
      delta author must be the submitter.
   - Manager
      - Includes Contributor capabilities
      - May add/remove members to/from the group and modify the role of
         - The member is self
         - The member is NOT a manager
         - The member is NOT an owner
      - Owner
      - Includes Manager capabilities
      - May add/remove members to/from the group and modify the role of
         - The member is self
         - The member is NOT an owner.
   - Reader
      - May read wavelet content
   - Contributor
      - Includes Reader capabilities
      - May add new wavelet content. In the context of a conversation
      wavelet, this implies adding new blips.
      - May edit own content. In the context of a conversation this implies
      editing or deleting own blips.
   - Editor
      - Includes Contributor capabilities
      - May add/edit/delete any content.
   - Manager
      - Includes Editor capabilities
      - May add/remove participants and modify the roles of any exiting
         - Participant is self
         - Participant is NOT a Manager
         - Participant is NOT an Owner
      - Owner
      - Includes Manager capabilities
      - May add/remove participants and modify the roles of any exiting
         - Participant is self
         - Participant is NOT an Owner
For both groups and wavelets the creator would be granted the owner role.
-Tad

[James Purser]

Wave Groups would be analogous to Email groups. Essentially a proxy for a
number of different users.

Essentially if you want to send a wave to the sales team you wouldn't
include everyones address in the wave, rather you would simply add
sales-9IKiO1iGCm/QT0dZR+***@public.gmane.org and it would appear in each sales group members inbox.

James

On Sat, Nov 27, 2010 at 11:30 AM, Michael MacFadden <

Post by Michael MacFadden
Tad,
Can you expand on exactly what the group functionality is? Is is just
a permissions scheme? Is it a new kind of model element (like a peer
to wavelet). I think the roles you define make sense, but I am
missing the bigger picture of what this functionality is all about.
~Michael

Post by Vega
That would be really important addition to wiab. By the way, how do
you intend to implement the groups functionality in wiab? Is it
related to google groups?

Post by Tad Glines
I'm working on adding group support to WiaB and also looking at the

issue of

Post by Vega

Post by Tad Glines
wavelet permissions.
As a starting point I want to propose some group and wavelet roles and
solicit feedback.
- Reader
- May read waves on which the group is a participant.
- Contributor
- Includes Reader capabilities
- May submit deltas to wavelets for which group is a participant.

The

Post by Vega

Post by Tad Glines
delta author must be the submitter.
- Manager
- Includes Contributor capabilities
- May add/remove members to/from the group and modify the role of
- The member is self
- The member is NOT a manager
- The member is NOT an owner
- Owner
- Includes Manager capabilities
- May add/remove members to/from the group and modify the role of
- The member is self
- The member is NOT an owner.
- Reader
- May read wavelet content
- Contributor
- Includes Reader capabilities
- May add new wavelet content. In the context of a conversation
wavelet, this implies adding new blips.
- May edit own content. In the context of a conversation this

implies

Post by Vega

Post by Tad Glines
editing or deleting own blips.
- Editor
- Includes Contributor capabilities
- May add/edit/delete any content.
- Manager
- Includes Editor capabilities
- May add/remove participants and modify the roles of any exiting
- Participant is self
- Participant is NOT a Manager
- Participant is NOT an Owner
- Owner
- Includes Manager capabilities
- May add/remove participants and modify the roles of any exiting
- Participant is self
- Participant is NOT an Owner
For both groups and wavelets the creator would be granted the owner

role.

Post by Vega

Post by Tad Glines
-Tad

--
You received this message because you are subscribed to the Google Groups
"Wave Protocol" group.
To unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.

[Rainfly]

Since Wave is not going to be a purely Google endeavor, I think it
should be something other than Google Groups, though we definitely
want to have some easy import/export features. Groups should be like
individual participants in that servers hold the group lists for all
groups in their domain (programmers-PV5Ro7/***@public.gmane.org would be some sort of
list of addresses stored on acme.com, but could contain users from any
domain).

Random side note: you can be in a wave in a group and as an individual
participant at the same time, but your individual status overrides
your group status, so individuals can be upgraded or downgraded while
the group's general settings remain the same.

Post by Vega
That would be really important addition to wiab. By the way, how do
you intend to implement the groups functionality in wiab? Is it
related to google groups?

Post by Tad Glines
I'm working on adding group support to WiaB and also looking at the issue of
wavelet permissions.
As a starting point I want to propose some group and wavelet roles and
solicit feedback.
   - Reader
      - May read waves on which the group is a participant.
   - Contributor
      - Includes Reader capabilities
      - May submit deltas to wavelets for which group is a participant. The
      delta author must be the submitter.
   - Manager
      - Includes Contributor capabilities
      - May add/remove members to/from the group and modify the role of
         - The member is self
         - The member is NOT a manager
         - The member is NOT an owner
      - Owner
      - Includes Manager capabilities
      - May add/remove members to/from the group and modify the role of
         - The member is self
         - The member is NOT an owner.
   - Reader
      - May read wavelet content
   - Contributor
      - Includes Reader capabilities
      - May add new wavelet content. In the context of a conversation
      wavelet, this implies adding new blips.
      - May edit own content. In the context of a conversation this implies
      editing or deleting own blips.
   - Editor
      - Includes Contributor capabilities
      - May add/edit/delete any content.
   - Manager
      - Includes Editor capabilities
      - May add/remove participants and modify the roles of any exiting
         - Participant is self
         - Participant is NOT a Manager
         - Participant is NOT an Owner
      - Owner
      - Includes Manager capabilities
      - May add/remove participants and modify the roles of any exiting
         - Participant is self
         - Participant is NOT an Owner
For both groups and wavelets the creator would be granted the owner role.
-Tad

[Nathanael Abbotts]

Love these propositions. They are exactly what I was asking for with
GWave.

Post by Vega
That would be really important addition to wiab. By the way, how do
you intend to implement the groups functionality in wiab? Is it
related to google groups?

Post by Tad Glines
I'm working on adding group support to WiaB and also looking at the issue of
wavelet permissions.
As a starting point I want to propose some group and wavelet roles and
solicit feedback.
   - Reader
      - May read waves on which the group is a participant.
   - Contributor
      - Includes Reader capabilities
      - May submit deltas to wavelets for which group is a participant. The
      delta author must be the submitter.
   - Manager
      - Includes Contributor capabilities
      - May add/remove members to/from the group and modify the role of
         - The member is self
         - The member is NOT a manager
         - The member is NOT an owner
      - Owner
      - Includes Manager capabilities
      - May add/remove members to/from the group and modify the role of
         - The member is self
         - The member is NOT an owner.
   - Reader
      - May read wavelet content
   - Contributor
      - Includes Reader capabilities
      - May add new wavelet content. In the context of a conversation
      wavelet, this implies adding new blips.
      - May edit own content. In the context of a conversation this implies
      editing or deleting own blips.
   - Editor
      - Includes Contributor capabilities
      - May add/edit/delete any content.
   - Manager
      - Includes Editor capabilities
      - May add/remove participants and modify the roles of any exiting
         - Participant is self
         - Participant is NOT a Manager
         - Participant is NOT an Owner
      - Owner
      - Includes Manager capabilities
      - May add/remove participants and modify the roles of any exiting
         - Participant is self
         - Participant is NOT an Owner
For both groups and wavelets the creator would be granted the owner role.
-Tad

[x00]

Those sound reasonable. However I think it really hard know for sure
how WIAB and derivatives are going to be used in the furure. It is
important that anything that is proposed doesn't create schism, when
there is a change of culture. that mean it has to be non limiting and
disposable. -

I while back I proposed a public via proxy "group" idea. The essence
is that interaction including access control is moderated by the proxy
agent, negating the need for predefined roles.

Groups and robots, etc will be hard to figure out how to federate.
Until something like distributed agent code, or simply a way to figure
out how to distribute defined interaction and automation is made. It
also has to perform it can't bee too slow.

[Alex North]

Post by x00
Those sound reasonable. However I think it really hard know for sure
how WIAB and derivatives are going to be used in the furure. It is
important that anything that is proposed doesn't create schism, when
there is a change of culture. that mean it has to be non limiting and
disposable. -
I while back I proposed a public via proxy "group" idea. The essence
is that interaction including access control is moderated by the proxy
agent, negating the need for predefined roles.

I don't recall this, so perhaps I didn't understand it when you proposed it.
Would you be willing to write a more detailed outline (in another thread or
a wave, perhaps)? Or point to one if you've already done so and I just
missed it.

Post by x00
Groups and robots, etc will be hard to figure out how to federate.
Until something like distributed agent code, or simply a way to figure
out how to distribute defined interaction and automation is made. It
also has to perform it can't bee too slow.
--
You received this message because you are subscribed to the Google Groups
"Wave Protocol" group.
To unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.

[x00]

I did ages ago, although some of it is redundant now. I'll make new
post.

[x00]

http://groups.google.com/group/wave-protocol/browse_frm/thread/1c2e04d78856e79b

[dougx]

Probably the single most requested feature from the people I work with
was the ability for a user to lock a blip so no one else could edit it
until they unlocked it (and, incidentally, that new blips were created
in a locked state).

I know that breaks the whole collaborate wave thing a bit, but a lot
of people I know were _really_ uncomfortable with having their
messages edited by other people (it only takes one prankster. :P), and
it made embedded waves a real mess. Having sections of a wave that
were collaborative, and sections that weren't was something that
people asked me about a lot.

I think it'd be relatively simple to modify the document model to
support a locked field for blips; federating that might be difficult,
but it'd work reasonably well for groups too.

I definitely think that locking at a blip level rather than a wavelet
level is needed.

~
Doug.

Post by Tad Glines
I'm working on adding group support to WiaB and also looking at the issue of
wavelet permissions.
As a starting point I want to propose some group and wavelet roles and
solicit feedback.
   - Reader
      - May read waves on which the group is a participant.
   - Contributor
      - Includes Reader capabilities
      - May submit deltas to wavelets for which group is a participant. The
      delta author must be the submitter.
   - Manager
      - Includes Contributor capabilities
      - May add/remove members to/from the group and modify the role of
         - The member is self
         - The member is NOT a manager
         - The member is NOT an owner
      - Owner
      - Includes Manager capabilities
      - May add/remove members to/from the group and modify the role of
         - The member is self
         - The member is NOT an owner.
   - Reader
      - May read wavelet content
   - Contributor
      - Includes Reader capabilities
      - May add new wavelet content. In the context of a conversation
      wavelet, this implies adding new blips.
      - May edit own content. In the context of a conversation this implies
      editing or deleting own blips.
   - Editor
      - Includes Contributor capabilities
      - May add/edit/delete any content.
   - Manager
      - Includes Editor capabilities
      - May add/remove participants and modify the roles of any exiting
         - Participant is self
         - Participant is NOT a Manager
         - Participant is NOT an Owner
      - Owner
      - Includes Manager capabilities
      - May add/remove participants and modify the roles of any exiting
         - Participant is self
         - Participant is NOT an Owner
For both groups and wavelets the creator would be granted the owner role.
-Tad

[Tad Glines]

This is certainly doable. We could put a <locked></locked> element at
the beginning of the document to indicate that it's locked. Only the
document author would be allowed to insert or delete a locked element. And
if the element is present, only the document creator would be allowed to
modify the document. This wouldn't be that hard to implement.

Instead of a locked element we could add an "owner" element at the
beginning, or maybe add "owner" and "locked" attributes to the contributor
element.

-Tad

Post by dougx
Probably the single most requested feature from the people I work with
was the ability for a user to lock a blip so no one else could edit it
until they unlocked it (and, incidentally, that new blips were created
in a locked state).
I know that breaks the whole collaborate wave thing a bit, but a lot
of people I know were _really_ uncomfortable with having their
messages edited by other people (it only takes one prankster. :P), and
it made embedded waves a real mess. Having sections of a wave that
were collaborative, and sections that weren't was something that
people asked me about a lot.
I think it'd be relatively simple to modify the document model to
support a locked field for blips; federating that might be difficult,
but it'd work reasonably well for groups too.
I definitely think that locking at a blip level rather than a wavelet
level is needed.
~
Doug.

Post by Tad Glines
I'm working on adding group support to WiaB and also looking at the issue

of

Post by Tad Glines
wavelet permissions.
As a starting point I want to propose some group and wavelet roles and
solicit feedback.
- Reader
- May read waves on which the group is a participant.
- Contributor
- Includes Reader capabilities
- May submit deltas to wavelets for which group is a participant.

The

Post by Tad Glines
delta author must be the submitter.
- Manager
- Includes Contributor capabilities
- May add/remove members to/from the group and modify the role of
- The member is self
- The member is NOT a manager
- The member is NOT an owner
- Owner
- Includes Manager capabilities
- May add/remove members to/from the group and modify the role of
- The member is self
- The member is NOT an owner.
- Reader
- May read wavelet content
- Contributor
- Includes Reader capabilities
- May add new wavelet content. In the context of a conversation
wavelet, this implies adding new blips.
- May edit own content. In the context of a conversation this

implies

Post by Tad Glines
editing or deleting own blips.
- Editor
- Includes Contributor capabilities
- May add/edit/delete any content.
- Manager
- Includes Editor capabilities
- May add/remove participants and modify the roles of any exiting
- Participant is self
- Participant is NOT a Manager
- Participant is NOT an Owner
- Owner
- Includes Manager capabilities
- May add/remove participants and modify the roles of any exiting
- Participant is self
- Participant is NOT an Owner
For both groups and wavelets the creator would be granted the owner role.
-Tad

--
You received this message because you are subscribed to the Google Groups
"Wave Protocol" group.
To unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.

[dougx]

Yup, that'd be neat.

Then just add a little locked / unlocked padlock icon in the ui (like
the osx settings panel), so users can see at a glance what elements of
the document they can modify. That'd be quite easy to add.

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...

~
Doug.

Post by Tad Glines
This is certainly doable. We could put a <locked></locked> element at
the beginning of the document to indicate that it's locked. Only the
document author would be allowed to insert or delete a locked element. And
if the element is present, only the document creator would be allowed to
modify the document. This wouldn't be that hard to implement.
Instead of a locked element we could add an "owner" element at the
beginning, or maybe add "owner" and "locked" attributes to the contributor
element.
-Tad

Post by dougx
Probably the single most requested feature from the people I work with
was the ability for a user to lock a blip so no one else could edit it
until they unlocked it (and, incidentally, that new blips were created
in a locked state).
I know that breaks the whole collaborate wave thing a bit, but a lot
of people I know were _really_ uncomfortable with having their
messages edited by other people (it only takes one prankster. :P), and
it made embedded waves a real mess. Having sections of a wave that
were collaborative, and sections that weren't was something that
people asked me about a lot.
I think it'd be relatively simple to modify the document model to
support a locked field for blips; federating that might be difficult,
but it'd work reasonably well for groups too.
I definitely think that locking at a blip level rather than a wavelet
level is needed.
~
Doug.

Post by Tad Glines
I'm working on adding group support to WiaB and also looking at the issue

of

Post by Tad Glines
wavelet permissions.
As a starting point I want to propose some group and wavelet roles and
solicit feedback.
   - Reader
      - May read waves on which the group is a participant.
   - Contributor
      - Includes Reader capabilities
      - May submit deltas to wavelets for which group is a participant.

The

Post by Tad Glines
      delta author must be the submitter.
   - Manager
      - Includes Contributor capabilities
      - May add/remove members to/from the group and modify the role of
         - The member is self
         - The member is NOT a manager
         - The member is NOT an owner
      - Owner
      - Includes Manager capabilities
      - May add/remove members to/from the group and modify the role of
         - The member is self
         - The member is NOT an owner.
   - Reader
      - May read wavelet content
   - Contributor
      - Includes Reader capabilities
      - May add new wavelet content. In the context of a conversation
      wavelet, this implies adding new blips.
      - May edit own content. In the context of a conversation this

implies

Post by Tad Glines
      editing or deleting own blips.
   - Editor
      - Includes Contributor capabilities
      - May add/edit/delete any content.
   - Manager
      - Includes Editor capabilities
      - May add/remove participants and modify the roles of any exiting
         - Participant is self
         - Participant is NOT a Manager
         - Participant is NOT an Owner
      - Owner
      - Includes Manager capabilities
      - May add/remove participants and modify the roles of any exiting
         - Participant is self
         - Participant is NOT an Owner
For both groups and wavelets the creator would be granted the owner role.
-Tad

--
You received this message because you are subscribed to the Google Groups
"Wave Protocol" group.
To unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.

[Vega]

I think Pamela Fox mentioned at the summit talks that they were
thinking about adding ability to lock any component in the wavelet, be
it blip, form or gadget. Maybe some kind of "locked" annotation...

Post by dougx
Yup, that'd be neat.
Then just add a little locked / unlocked padlock icon in the ui (like
the osx settings panel), so users can see at a glance what elements of
the document they can modify. That'd be quite easy to add.
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...
~
Doug.

Post by Tad Glines
This is certainly doable. We could put a <locked></locked> element at
the beginning of the document to indicate that it's locked. Only the
document author would be allowed to insert or delete a locked element. And
if the element is present, only the document creator would be allowed to
modify the document. This wouldn't be that hard to implement.
Instead of a locked element we could add an "owner" element at the
beginning, or maybe add "owner" and "locked" attributes to the contributor
element.
-Tad

Post by dougx
Probably the single most requested feature from the people I work with
was the ability for a user to lock a blip so no one else could edit it
until they unlocked it (and, incidentally, that new blips were created
in a locked state).
I know that breaks the whole collaborate wave thing a bit, but a lot
of people I know were _really_ uncomfortable with having their
messages edited by other people (it only takes one prankster. :P), and
it made embedded waves a real mess. Having sections of a wave that
were collaborative, and sections that weren't was something that
people asked me about a lot.
I think it'd be relatively simple to modify the document model to
support a locked field for blips; federating that might be difficult,
but it'd work reasonably well for groups too.
I definitely think that locking at a blip level rather than a wavelet
level is needed.
~
Doug.

Post by Tad Glines
I'm working on adding group support to WiaB and also looking at the issue

of

Post by Tad Glines
wavelet permissions.
As a starting point I want to propose some group and wavelet roles and
solicit feedback.
   - Reader
      - May read waves on which the group is a participant.
   - Contributor
      - Includes Reader capabilities
      - May submit deltas to wavelets for which group is a participant.

The

Post by Tad Glines
      delta author must be the submitter.
   - Manager
      - Includes Contributor capabilities
      - May add/remove members to/from the group and modify the role of
         - The member is self
         - The member is NOT a manager
         - The member is NOT an owner
      - Owner
      - Includes Manager capabilities
      - May add/remove members to/from the group and modify the role of
         - The member is self
         - The member is NOT an owner.
   - Reader
      - May read wavelet content
   - Contributor
      - Includes Reader capabilities
      - May add new wavelet content. In the context of a conversation
      wavelet, this implies adding new blips.
      - May edit own content. In the context of a conversation this

implies

Post by Tad Glines
      editing or deleting own blips.
   - Editor
      - Includes Contributor capabilities
      - May add/edit/delete any content.
   - Manager
      - Includes Editor capabilities
      - May add/remove participants and modify the roles of any exiting
         - Participant is self
         - Participant is NOT a Manager
         - Participant is NOT an Owner
      - Owner
      - Includes Manager capabilities
      - May add/remove participants and modify the roles of any exiting
         - Participant is self
         - Participant is NOT an Owner
For both groups and wavelets the creator would be granted the owner role.
-Tad

--
You received this message because you are subscribed to the Google Groups
"Wave Protocol" group.
To unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.

[Tad Glines]

Post by dougx
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.

Implementation in the server shouldn't be that complicated.

-Tad

[Torben Weis]

Post by Tad Glines

Post by dougx
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

Post by Tad Glines
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 unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.

--
---------------------------
Prof. Torben Weis
Universitaet Duisburg-Essen
torben.weis-***@public.gmane.org

[John Blossom]

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.

Post by Torben Weis

Post by Tad Glines

Post by dougx
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

Post by Tad Glines
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 unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.

--
---------------------------
Prof. Torben Weis
Universitaet Duisburg-Essen

[Tad Glines]

Post by Torben Weis
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?

I'm not sure about the concurrency control code in WiaB, but the stuff I
implemented last year was able to transform the pending ops against the
rejected delta.

Post by Torben Weis
My guess is that no client currently handles this in a reasonable way and
therefore this is a rather major change.

Correct. My stuff didn't handle it in an idea manor from the user's point of
view. The user would see their changes disappear with no explanation why.

Post by Torben Weis
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!

An intermediate solution to the whole race condition problem is to require
that if a blip is to be locked, it must be created lock, and can
subsequently only be unlocked, but not re-locked. From a UI point of view,
there would be a lock icon or lock check-box that appears in the blip during
creation/editing if the wavelet supports blip locking and the user has
permission to create locked blips. Then the initial lock state of the a blip
during creation would be a user preference.

-Tad

[dougx]

I'd resolve large (by some threshold) uncommitable changes as a new
private wavelet inline at that position with an error message and the
uncommitted changes and only the changer as a member of the wavelet.
The user can then keep their changes, apply them somehow (new blip,
etc. as they choose) but we guaruntee that the action is permissible
for the user (private replies are always possible, regardless of the
permission model; at least initially).

~
Doug.

Post by Tad Glines

Post by Torben Weis
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?

I'm not sure about the concurrency control code in WiaB, but the stuff I
implemented last year was able to transform the pending ops against the
rejected delta.

Post by Torben Weis
My guess is that no client currently handles this in a reasonable way and
therefore this is a rather major change.

Correct. My stuff didn't handle it in an idea manor from the user's point of
view. The user would see their changes disappear with no explanation why.

Post by Torben Weis
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!

An intermediate solution to the whole race condition problem is to require
that if a blip is to be locked, it must be created lock, and can
subsequently only be unlocked, but not re-locked. From a UI point of view,
there would be a lock icon or lock check-box that appears in the blip during
creation/editing if the wavelet supports blip locking and the user has
permission to create locked blips. Then the initial lock state of the a blip
during creation would be a user preference.
-Tad

[Vega]

I still would like to know the details of actual implementation. Some
kind of design doc that precedes actual coding would be very nice,
that would allow the community to take part in the low level design.
Or even to take part in actual coding.

One more thing that I want to talk about is the whole concept of
public/private wavelets. The current default wavelet mode is
"private", i.e. only participants can have access. How about changing
the default mode to "public"? So, every wavelet is public until stated
otherwise? I think it makes a lot more sense for a collaboration
platform to be public by default.

Post by dougx
I'd resolve large (by some threshold) uncommitable changes as a new
private wavelet inline at that position with an error message and the
uncommitted changes and only the changer as a member of the wavelet.
The user can then keep their changes, apply them somehow (new blip,
etc. as they choose) but we guaruntee that the action is permissible
for the user (private replies are always possible, regardless of the
permission model; at least initially).
~
Doug.

Post by Tad Glines

Post by Torben Weis
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?

I'm not sure about the concurrency control code in WiaB, but the stuff I
implemented last year was able to transform the pending ops against the
rejected delta.

Post by Torben Weis
My guess is that no client currently handles this in a reasonable way and
therefore this is a rather major change.

Correct. My stuff didn't handle it in an idea manor from the user's point of
view. The user would see their changes disappear with no explanation why.

Post by Torben Weis
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!

An intermediate solution to the whole race condition problem is to require
that if a blip is to be locked, it must be created lock, and can
subsequently only be unlocked, but not re-locked. From a UI point of view,
there would be a lock icon or lock check-box that appears in the blip during
creation/editing if the wavelet supports blip locking and the user has
permission to create locked blips. Then the initial lock state of the a blip
during creation would be a user preference.
-Tad

[Ian Roughley]

Post by Vega
I still would like to know the details of actual implementation. Some
kind of design doc that precedes actual coding would be very nice,
that would allow the community to take part in the low level design.
Or even to take part in actual coding.

Agreed. It would also help me reconcile our implementation with what' proposed. With groups, and
any feature actually, we also need to take into account what effects the feature will have on the
federation protocol. From the summit, groups in particular can get a little complex fast.

Post by Vega
One more thing that I want to talk about is the whole concept of
public/private wavelets. The current default wavelet mode is
"private", i.e. only participants can have access. How about changing
the default mode to "public"? So, every wavelet is public until stated
otherwise? I think it makes a lot more sense for a collaboration
platform to be public by default.

Post by dougx
I'd resolve large (by some threshold) uncommitable changes as a new
private wavelet inline at that position with an error message and the
uncommitted changes and only the changer as a member of the wavelet.
The user can then keep their changes, apply them somehow (new blip,
etc. as they choose) but we guaruntee that the action is permissible
for the user (private replies are always possible, regardless of the
permission model; at least initially).
~
Doug.

Post by Tad Glines

Post by Torben Weis
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?

I'm not sure about the concurrency control code in WiaB, but the stuff I
implemented last year was able to transform the pending ops against the
rejected delta.

Post by Torben Weis
My guess is that no client currently handles this in a reasonable way and
therefore this is a rather major change.

Correct. My stuff didn't handle it in an idea manor from the user's point of
view. The user would see their changes disappear with no explanation why.

Post by Torben Weis
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!

An intermediate solution to the whole race condition problem is to require
that if a blip is to be locked, it must be created lock, and can
subsequently only be unlocked, but not re-locked. From a UI point of view,
there would be a lock icon or lock check-box that appears in the blip during
creation/editing if the wavelet supports blip locking and the user has
permission to create locked blips. Then the initial lock state of the a blip
during creation would be a user preference.
-Tad

[Alex North]

Post by Torben Weis

Post by Tad Glines

Post by dougx
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.

Post by Torben Weis
Torben

Post by Tad Glines
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 unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.

--
---------------------------
Prof. Torben Weis
Universitaet Duisburg-Essen
--
You received this message because you are subscribed to the Google Groups
"Wave Protocol" group.
To unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.

[Torben Weis]

Post by Alex North

Post by Alex North
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.

Post by Alex North
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.

Torben

Post by Alex North

Post by Alex North
Torben

Post by Tad Glines
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 unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.

--
---------------------------
Prof. Torben Weis
Universitaet Duisburg-Essen
--
You received this message because you are subscribed to the Google Groups
"Wave Protocol" group.
To unsubscribe from this group, send email to
.
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 unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.

--
---------------------------
Prof. Torben Weis
Universitaet Duisburg-Essen
torben.weis-***@public.gmane.org

[Alex North]

Post by Torben Weis

Post by Alex North

Post by Alex North
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.

Post by Torben Weis

Post by Alex North
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.

Post by Torben Weis
Torben

Post by Alex North

Post by Alex North
Torben

Post by Tad Glines
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 unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.

--
---------------------------
Prof. Torben Weis
Universitaet Duisburg-Essen
--
You received this message because you are subscribed to the Google Groups
"Wave Protocol" group.
To unsubscribe from this group, send email to
.
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 unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.

--
---------------------------
Prof. Torben Weis
Universitaet Duisburg-Essen
--
You received this message because you are subscribed to the Google Groups
"Wave Protocol" group.
To unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.

[Torben Weis]

Post by Alex North

Post by Torben Weis

Post by Alex North
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.

Post by Alex North

Post by Torben Weis

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

Post by Alex North

Post by Torben Weis
Torben

Post by Alex North
Torben

Post by Tad Glines
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 unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.

--
---------------------------
Prof. Torben Weis
Universitaet Duisburg-Essen
--
You received this message because you are subscribed to the Google
Groups "Wave Protocol" group.
To unsubscribe from this group, send email to
.
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 unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.

--
---------------------------
Prof. Torben Weis
Universitaet Duisburg-Essen
--
You received this message because you are subscribed to the Google Groups
"Wave Protocol" group.
To unsubscribe from this group, send email to
.
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 unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.

--
---------------------------
Prof. Torben Weis
Universitaet Duisburg-Essen
torben.weis-***@public.gmane.org

[STenyaK]

I'm not actively involved in wiab development, but here's some thoughts:

I think we can all agree that Wave is suitable for replacing many
communications forms: email, mailing lists, forums, doodles, wikis,
google docs...
Each one of these existing communications forms exist and is widely
used, because it suits certain usage patterns.

If[*] wave's "purpose" is to be able to replace all of these other
forms, the groups/permissions system must be a superset of all the
options available in current communication forms. Otherwise, we'll
find use cases in which Wave is not suitable for some reason or
another, therefore giving people valid excuses not to migrate to Wave,
and keep the current mess of communications we have nowadays.

If we apply this idea to groups/permissions, then we should be able to
make any blip non-editable by anyone (email style), or editable only
by owner and "admin" group (forums), or rejectable by "admin" group
before it's published (moderated mailing list), etc.
Note that the above is just a very very simple example so that you get
an idea of what I mean.

When trying to come up with that superset of features, it'll probably
be possible to refactor them into a much smaller set of
rules/features, that combined together in certain ways can replicate
the behaviour of existing communication forms. In my opinion, we
should strive for that.

[*] That's what I'd like wave to become, but other people may
disagree. I'm not sure if there's even an official definition of what
wave tries to be?

Post by Tad Glines
I'm working on adding group support to WiaB and also looking at the issue of
wavelet permissions.
As a starting point I want to propose some group and wavelet roles and
solicit feedback.
Reader
May read waves on which the group is a participant.
Contributor
Includes Reader capabilities
May submit deltas to wavelets for which group is a participant. The delta
author must be the submitter.
Manager
Includes Contributor capabilities
May add/remove members to/from the group and modify the role of existing
The member is self
The member is NOT a manager
The member is NOT an owner
Owner
Includes Manager capabilities
May add/remove members to/from the group and modify the role of existing
The member is self
The member is NOT an owner.
Reader
May read wavelet content
Contributor
Includes Reader capabilities
May add new wavelet content. In the context of a conversation wavelet, this
implies adding new blips.
May edit own content. In the context of a conversation this implies editing
or deleting own blips.
Editor
Includes Contributor capabilities
May add/edit/delete any content.
Manager
Includes Editor capabilities
May add/remove participants and modify the roles of any exiting participant
Participant is self
Participant is NOT a Manager
Participant is NOT an Owner
Owner
Includes Manager capabilities
May add/remove participants and modify the roles of any exiting participant
Participant is self
Participant is NOT an Owner
For both groups and wavelets the creator would be granted the owner role.
-Tad
--
You received this message because you are subscribed to the Google Groups
"Wave Protocol" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.

--
Saludos,
     Bruno González

_______________________________________________
Jabber: stenyak AT gmail.com
http://www.stenyak.com

[ThomasWrobel]

I'm certainly in favour of as flexible as possible edit system.
A creator of a blip being able to set who else can edit it, or to make
it totaly read-only would be incredibly usefull for the use-case I'm
working on. Ditto for the whole wave. Read-only, adding, full edit
etc.

My only issue would be just a minor one over naming.
Contributor all be a bit too technical-sounding for a casual user.
(and while clients are free to abstract/rename as they please, it
would be nice to keep a uniform naming to some extent). So Id suggest
trying to keep things friendly/easy as possible for regular users to
understand. In many ways it should be as simple as sharing google-
documents and setting editing permissions on those.

Post by STenyaK
I think we can all agree that Wave is suitable for replacing many
communications forms: email, mailing lists, forums, doodles, wikis,
google docs...
Each one of these existing communications forms exist and is widely
used, because it suits certain usage patterns.
If[*] wave's "purpose" is to be able to replace all of these other
forms, the groups/permissions system must be a superset of all the
options available in current communication forms. Otherwise, we'll
find use cases in which Wave is not suitable for some reason or
another, therefore giving people valid excuses not to migrate to Wave,
and keep the current mess of communications we have nowadays.
If we apply this idea to groups/permissions, then we should be able to
make any blip non-editable by anyone (email style), or editable only
by owner and "admin" group (forums), or rejectable by "admin" group
before it's published (moderated mailing list), etc.
Note that the above is just a very very simple example so that you get
an idea of what I mean.
When trying to come up with that superset of features, it'll probably
be possible to refactor them into a much smaller set of
rules/features, that combined together in certain ways can replicate
the behaviour of existing communication forms. In my opinion, we
should strive for that.
[*] That's what I'd like wave to become, but other people may
disagree. I'm not sure if there's even an official definition of what
wave tries to be?

Post by Tad Glines
I'm working on adding group support to WiaB and also looking at the issue of
wavelet permissions.
As a starting point I want to propose some group and wavelet roles and
solicit feedback.
Reader
May read waves on which the group is a participant.
Contributor
Includes Reader capabilities
May submit deltas to wavelets for which group is a participant. The delta
author must be the submitter.
Manager
Includes Contributor capabilities
May add/remove members to/from the group and modify the role of existing
The member is self
The member is NOT a manager
The member is NOT an owner
Owner
Includes Manager capabilities
May add/remove members to/from the group and modify the role of existing
The member is self
The member is NOT an owner.
Reader
May read wavelet content
Contributor
Includes Reader capabilities
May add new wavelet content. In the context of a conversation wavelet, this
implies adding new blips.
May edit own content. In the context of a conversation this implies editing
or deleting own blips.
Editor
Includes Contributor capabilities
May add/edit/delete any content.
Manager
Includes Editor capabilities
May add/remove participants and modify the roles of any exiting participant
Participant is self
Participant is NOT a Manager
Participant is NOT an Owner
Owner
Includes Manager capabilities
May add/remove participants and modify the roles of any exiting participant
Participant is self
Participant is NOT an Owner
For both groups and wavelets the creator would be granted the owner role.
-Tad
--
You received this message because you are subscribed to the Google Groups
"Wave Protocol" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.

--
Saludos,
     Bruno González
_______________________________________________
Jabber: stenyak AT gmail.comhttp://www.stenyak.com

[Alex North]

Post by STenyaK
I think we can all agree that Wave is suitable for replacing many
communications forms: email, mailing lists, forums, doodles, wikis,
google docs...
Each one of these existing communications forms exist and is widely
used, because it suits certain usage patterns.
If[*] wave's "purpose" is to be able to replace all of these other
forms, the groups/permissions system must be a superset of all the
options available in current communication forms. Otherwise, we'll
find use cases in which Wave is not suitable for some reason or
another, therefore giving people valid excuses not to migrate to Wave,
and keep the current mess of communications we have nowadays.
If we apply this idea to groups/permissions, then we should be able to
make any blip non-editable by anyone (email style), or editable only
by owner and "admin" group (forums), or rejectable by "admin" group
before it's published (moderated mailing list), etc.
Note that the above is just a very very simple example so that you get
an idea of what I mean.
When trying to come up with that superset of features, it'll probably
be possible to refactor them into a much smaller set of
rules/features, that combined together in certain ways can replicate
the behaviour of existing communication forms. In my opinion, we
should strive for that.
[*] That's what I'd like wave to become, but other people may
disagree. I'm not sure if there's even an official definition of what
wave tries to be?

I'm going to have to disagree here. Trying to be all things to all people
was one of the fundamental weaknesses in Google Wave. It led to a complex
product that was kinda good at lots of things, but not fantastic at any.
Over time we iterated towards document/wiki style collaboration as one use
case at which Wave particularly excelled, but it was still a bit confusing.

I don't think having a "purpose" of replacing all those systems is a good
idea. It will lead to huge amounts of both product and technical complexity.
I would much prefer WIAB focussed on a smaller target, at least to start.
The one I would suggest it's closest to already is small group
collaboration.

But that's just my opinion. Perhaps this community should work towards
agreeing on a target ideal.

Post by STenyaK

Post by Tad Glines
I'm working on adding group support to WiaB and also looking at the issue

of

Post by Tad Glines
wavelet permissions.
As a starting point I want to propose some group and wavelet roles and
solicit feedback.
Reader
May read waves on which the group is a participant.
Contributor
Includes Reader capabilities
May submit deltas to wavelets for which group is a participant. The delta
author must be the submitter.
Manager
Includes Contributor capabilities
May add/remove members to/from the group and modify the role of existing
The member is self
The member is NOT a manager
The member is NOT an owner
Owner
Includes Manager capabilities
May add/remove members to/from the group and modify the role of existing
The member is self
The member is NOT an owner.
Reader
May read wavelet content
Contributor
Includes Reader capabilities
May add new wavelet content. In the context of a conversation wavelet,

this

Post by Tad Glines
implies adding new blips.
May edit own content. In the context of a conversation this implies

editing

Post by Tad Glines
or deleting own blips.
Editor
Includes Contributor capabilities
May add/edit/delete any content.
Manager
Includes Editor capabilities
May add/remove participants and modify the roles of any exiting

participant

Post by Tad Glines
Participant is self
Participant is NOT a Manager
Participant is NOT an Owner
Owner
Includes Manager capabilities
May add/remove participants and modify the roles of any exiting

participant

Post by Tad Glines
Participant is self
Participant is NOT an Owner
For both groups and wavelets the creator would be granted the owner role.
-Tad
--
You received this message because you are subscribed to the Google Groups
"Wave Protocol" group.
To unsubscribe from this group, send email to

.

Post by Tad Glines
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.

--
Saludos,
Bruno González
_______________________________________________
Jabber: stenyak AT gmail.com
http://www.stenyak.com
--
You received this message because you are subscribed to the Google Groups
"Wave Protocol" group.
To unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.

[Jeremy NGL]

Post by STenyaK

Post by STenyaK
(...)

I think we can all agree that Wave is suitable for replacing many

Post by STenyaK
communications forms: email, mailing lists, forums, doodles, wikis,
google docs... Each one of these existing communications forms exist

and is widely used, because it suits certain usage patterns.

Post by STenyaK
If[*] wave's "purpose" is to be able to replace all of these other
forms, the groups/permissions system must be a superset of all the
options available in current communication forms. Otherwise, we'll
find use cases in which Wave is not suitable for some reason or
another, therefore giving people valid excuses not to migrate to Wave,
and keep the current mess of communications we have nowadays.
(...)
[*] That's what I'd like wave to become, but other people may
disagree. I'm not sure if there's even an official definition of what
wave tries to be?

I'm going to have to disagree here. Trying to be all things to all people

Post by STenyaK
was one of the fundamental weaknesses in Google Wave. It led to a complex
product that was kinda good at lots of things, but not fantastic at any.
Over time we iterated towards document/wiki style collaboration as one use
case at which Wave particularly excelled, but it was still a bit confusing.
I don't think having a "purpose" of replacing all those systems is a good
idea. It will lead to huge amounts of both product and technical complexity.
I would much prefer WIAB focussed on a smaller target, at least to start.
The one I would suggest it's closest to already is small group
collaboration.
But that's just my opinion. Perhaps this community should work towards
agreeing on a target ideal.

Hi Alex,

I'd like to share my opinion (even if this mailing list is going to be off
soon) as I partly disagree here.

What I immediately loved about Wave is it's ability to replace a lot of web
services I was using... I could imagine myself doing almost all my
web-things from it (write mails, write Note to myself, paste web content I
want to save, write blog articles - collaboratively or not, use it for
forum-like usage on topics I'm interested in, wiki-like usage, chat usage,
social usage, etc...). It may not be absolutely perfect at all those things
but having one tool instead of ten was such an improvement. In fact from
November 2009 to July 2010, I think that 75% of my previous time spent on
the web became time spent on Wave !

Let me also quote a nice blog-post :
*"* (...) Wave is a flexible and generic platform, one that can be used for
groups discussion, for diary entries, for event commentary, for surveys. Of
course, there are existing solutions for doing each of those things - but
there is not one solution that does all of them. (...) There are of course
reasons for using specialized tools (...) but when you're collaborating with
your group of colleagues (...), I've found it's better 99% of the time to
have the flexibility of Wave than the specialized features of 10 different
services at once. That's why I will find it hard to stop using Wave (and I
hope I don't have to), because I would have to replace it with myriad
different tools. *"*

The source is http://blog.pamelafox.org/2010/12/why-i-loved-wave.html ;-)

Of course, I'm not saying that WiaB purpose should be to replace all
existing communication tools, that's an utopia and that would be a huge
mistake.
I agree that Wave's complexity was a fundamental weakness of the product...
but on the other hand, it's its flexibility that made it so great and
revolutionary !

I think it's great right now to target small group collaboration, but I hope
the WiaB project won't let Public waving aside...
This ability to add Public to our waves was IMHO a breakthrough feature, one
that really differentiated Wave from Email.

Of course with public waving also came public wave vandalism and trolling...
That brings me back to this thread's topic : permissions.

Google Wave's setting "Full access" meant vulnerability, and "Read only"
meant the end of public inputs and open collaboration...
According to a live chat with Lars Rasmussen a year ago, a third setting
"Reply only" was on its way... This was badly needed IMHO !

As I said, I hope Public waving will live on with WiaB, and I hope you'll
find the correct permissions settings to manage it.

Thanks to all of you guys for keeping the Wave technology alive !

Best regards,
Jeremy.

[Alex North]

Thanks for starting this off Tad. I too think adding groups support is an
important feature to work on, perhaps in the new year after our initial WIAB
task list<https://sites.google.com/a/waveprotocol.org/wave-protocol/code/wave-in-a-box-task-list?pli=1>is
complete.

I've refrained from responding earlier because groups and access control are
complex issues and I wanted to have time to think deeply about your
proposals. Some of the Googlers here have a lot of knowledge from
implementing groups and (some) access control in Google Wave which I hope
can inform WIABs implementation. I'm not suggesting WIAB should do exactly
the same thing, but we learned some important things which it would be
unfortunate to need to re-learn the hard way.

In particular, Google Wave's very simple roles system arose because defining
robust access control in Wave is very difficult. We never reached a design
that we were happy with, though we have ideas about what an appropriate
design might look like.

I'm glad that in future messages you've separated the concerns of groups
from those of wavelet access control. They are clearly related, but they are
also relatively independent. IMO groups support is both more valuable as a
product feature and easier to implement (and educational), so I'd suggest
focussing on that first. Keep access control in mind, but I think we'll get
rapidly confused if we try to do everything at once.

I'll respond to a few of the smaller comments in these threads now. However,
groups is definitely something that warrants a thorough design before we
write too much code. Email is unfortunately a poor medium for iterating on
designs, so I propose using either a Wave or a Google Doc.

A.

Post by Tad Glines
I'm working on adding group support to WiaB and also looking at the issue
of wavelet permissions.
As a starting point I want to propose some group and wavelet roles and
solicit feedback.
- Reader
- May read waves on which the group is a participant.
- Contributor
- Includes Reader capabilities
- May submit deltas to wavelets for which group is a participant.
The delta author must be the submitter.
- Manager
- Includes Contributor capabilities
- May add/remove members to/from the group and modify the role of
- The member is self
- The member is NOT a manager
- The member is NOT an owner
- Owner
- Includes Manager capabilities
- May add/remove members to/from the group and modify the role of
- The member is self
- The member is NOT an owner.
- Reader
- May read wavelet content
- Contributor
- Includes Reader capabilities
- May add new wavelet content. In the context of a conversation
wavelet, this implies adding new blips.
- May edit own content. In the context of a conversation this
implies editing or deleting own blips.
- Editor
- Includes Contributor capabilities
- May add/edit/delete any content.
- Manager
- Includes Editor capabilities
- May add/remove participants and modify the roles of any exiting
- Participant is self
- Participant is NOT a Manager
- Participant is NOT an Owner
- Owner
- Includes Manager capabilities
- May add/remove participants and modify the roles of any exiting
- Participant is self
- Participant is NOT an Owner
For both groups and wavelets the creator would be granted the owner role.
-Tad
--
You received this message because you are subscribed to the Google Groups
"Wave Protocol" group.
To unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.

[Alex North]

Post by Tad Glines
I'm working on adding group support to WiaB and also looking at the issue
of wavelet permissions.
As a starting point I want to propose some group and wavelet roles and
solicit feedback.
- Reader
- May read waves on which the group is a participant.
- Contributor
- Includes Reader capabilities
- May submit deltas to wavelets for which group is a participant.
The delta author must be the submitter.
- Manager
- Includes Contributor capabilities
- May add/remove members to/from the group and modify the role of
- The member is self
- The member is NOT a manager
- The member is NOT an owner
- Owner
- Includes Manager capabilities
- May add/remove members to/from the group and modify the role of
- The member is self
- The member is NOT an owner.
- Reader
- May read wavelet content
- Contributor
- Includes Reader capabilities
- May add new wavelet content. In the context of a conversation
wavelet, this implies adding new blips.
- May edit own content. In the context of a conversation this
implies editing or deleting own blips.
- Editor
- Includes Contributor capabilities
- May add/edit/delete any content.
- Manager
- Includes Editor capabilities
- May add/remove participants and modify the roles of any exiting
- Participant is self
- Participant is NOT a Manager
- Participant is NOT an Owner
- Owner
- Includes Manager capabilities
- May add/remove participants and modify the roles of any exiting
- Participant is self
- Participant is NOT an Owner

I think this is rather too complex for wavelet permissions. In particular, I
think it's counter-productive that only Managers and above can add
participants. Sharing a wavelet is fundamentally valuable so in a linear
hierachy like this I think it should appear around editor or contributor.
This implies the Manager role is redundant.

Perhaps some use cases describing some typical collaboration scenarios would
help settle this list. It's also not clear that a linear hierachy is the
right model, as opposed to orthogonal capabilities, though it does have the
advantage of being simple.

Post by Tad Glines
For both groups and wavelets the creator would be granted the owner role.
-Tad
--
You received this message because you are subscribed to the Google Groups
"Wave Protocol" group.
To unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.

[Tad Glines]

Post by Alex North
I think this is rather too complex for wavelet permissions. In particular,
I think it's counter-productive that only Managers and above can add
participants. Sharing a wavelet is fundamentally valuable so in a linear
hierachy like this I think it should appear around editor or contributor.
This implies the Manager role is redundant.
Perhaps some use cases describing some typical collaboration scenarios
would help settle this list. It's also not clear that a linear hierachy is
the right model, as opposed to orthogonal capabilities, though it does have
the advantage of being simple.

At the time I thought of those roles I hadn't yet worked out a capabilities
model that could be used to represent those roles as well as others.
What's in the groups notes wavelet is more thought out but still needs work.

-Tad

[x00]

I think the biggest mistake is setting aside federation, like you will
figure that out later. This kind of mistake has been made before.

[Tad Glines]

Post by x00
I think the biggest mistake is setting aside federation, like you will
figure that out later. This kind of mistake has been made before.

I have not set aside federation. Where did you get that idea?

-Tad