[WebODF] Proposal for solution of current memberdata needs

[Philip Peitsch]

On 05/11/2013, at 3:43 AM, Friedrich W. H. Kossebau wrote:

> Now with OwnCloud we have the case that any member which leaves the session 
> has to do a save, and for that it would need to set the doc's metadata 
> <office:meta><dc:creator/></office:meta> up-to-date about the person which did 
> the last modification WRT the saved state, following the ODF spec §4.3.2.7 
> <dc:creator>, which defines that <dc:creator> "specifies the name of the 
> person who last modified a document".
> Meaning, any member's client needs to be able to know the fullname of any 
> other member in case.

I'm a little hazy about the link between a member leaving causing a save, and why
this requires every other client to have the full name. Isn't the member that is leaving
responsible for requesting the document is saved? Don't they then have the opportunity
to update the meta-data before then? Or are you talking about the a member abnormally
terminating their session (e.g., browser crash)?

I guess the key question I'm asking is why would another client set the dc:creator
attribute to someone other than itself without a specific Op telling it the new value?

> Ideally the server/host is the one single source for all data about members, 
> so clients could not play evil to each other and pretend members to be someone 
> else, by passing e.g. faked fullname and avatar ids.

+1


> Demand:
> 
> So, how to enable clients/members to create opspecs with member detail of 
> other members, more specific, use the fullname to set for <dc:creator>?

Putting aside my confusion on the initial problem, I can see other good reasons for
all clients to have access to this data anyways. So my +1 for this.


> Proposal:
> 
> Member metadata is added to the extended ODF model, as session-only data like 
> cursors are, instead of being maintained in a separate pool.
> 
> There would be new ops: OpAddMember, OpUpdateMember and OpRemoveMember.
> 
> The hosting system (in owncloud case the server, in local mode the local 
> system) would create and insert these ops into the op stack:
> * OpAddMember to tell about a new member and the metadata (fullname, avatar, 
> color, editing rights, session_enter_time, idling/afk/pending connection..., 
> etc)
> Would be inserted during the successful enterSession call by a client
> 
> * OpUpdateMember to tell about any change with a member's metadata
> would be inserted by the host on any change of the metadata.
> 
> * OpRemoveMember to tell that a member has left the session. 
> Would be inserted by the host if the client calls leaveSession or is kicked 
> out. The current memberdata (fullname, color, etc) itself should be kept 
> around at clients, for the case that it is needed for some rendering of 
> session data.

The last part of this is impl-specific. The member data is only required if the
consumer of the events will continue to show information about that member.
I still agree with the premise though!

Is it possible for additional ops to be generated for a member that is no longer
part of the session? Perhaps we should include that as a guarantee (or specifically
highlight that it is possible to receive additional events up to X mins after removal).


> No idea if that would also work with Peer2Peer, is ignored for this solution 
> as it's not a target currently.

These ops all make sense to me.

I would suggest most member properties are treated as a grab-bag of strings, as
I can see different consumers might like to add additional meta-data useful
for their own display (or omit data they don't care about). E.g., a node-based editor
would probably not want to specify an avatar or colour, or perhaps a custom viewer
will allow a status to be displayed along side a member's avatar.


> The OpAddMember op for a new member should be part of the opstack before the 
> client queries the genesis doc and the current op stack. That should be 
> expected, due to adding that during the enterSession query from the client, so 
> before any genesis doc & opstack fetching.
> 
> Any client should only start to create own operations once it has received and 
> replayed the OpAddMember of its own member (because only then it has got the 
> full details about himself, like the fullname).
> 
> For the transition period the existing MemberModel could be just a wrapper to 
> the member model which should be part of ops.OdtDocument, and later could be 
> merged into the normal ops.OdtDocument API.

+1 for merging into OdtDocument. Basically, all data in OdtDocument should only
be updated via operations (imo)… so once the data *is* controlled via ops, it can
now be safely accessed and used within other operations right?


> What do you think? Are there any holes in the concept? Too complicated? Or 
> simply brilliant? Alternative ideas?

I'm happy enough with this. It seems like a simple concept, and trivially easy to
make OT safe. I like the idea of using the operations queue in this fashion.

Queries I have:
1. How will you prevent op reordering from causing multiple clients believing
the other client was the last updater of the document? E.g., client A believes
the last op was from client B, and client B believes vice-versa as the local
operation order is different on each side.

2. Are these operations intended to be undo-able? (Ignoring the current
broken-ish undo stack… I mean the-undo-concept :) ). We can easily
generate the inverse op, but I'm wondering more whether the local user
who just changed their name ever expects undo to revert that name
change.

> 
> Cheers
> Friedrich
> 
> PS: As reminder, as sketched now and then some future support for chatting 
> might be done in a similar way, by extending the odf model and doing the 
> messages as operations.

+100 ^_^