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:metadc:creator/ 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 ^_^