Hi, current situation: there are two operations (one existing, one hypothetical) which create/modify datastructures with the element <dc:creator>: * OpAddAnnotation * OpSetMetadata (would update e.g. <office:meta><dc:creator/></office:meta>) (Ignoring <office:meta><meta:initial-creator/></office:meta> here for now, creating new documents from templates is a separate problem, not thought in detail about that yet) Issue is that ideally the opspec has all data needed for execution and does not need to query for/lookup anything. Also ops currently cannot access the membermodel, as they only see the ops.OdtDocument object, but not the ops.Session one. OpAddAnnotation ATM breaks that concept, as it relies on the execution method (or rather AnnotationViewManager) to set the proper content for <dc;creator>. <dc:creator> would be passed by OpAddAnnotation by the same member, so just the member would need to know what data it should set in, usally the fullname of the member. In the possible case of the change of the fullname it would be a nice feature to have the <dc:creator> of (at least) all annotations created in the current session be updated. That would need a new method OpUpdateAnnotation, but that still would/could be initiated by the member whose fullname changed. 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. 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. 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>? 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. No idea if that would also work with Peer2Peer, is ignored for this solution as it's not a target currently. 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. What do you think? Are there any holes in the concept? Too complicated? Or simply brilliant? Alternative ideas? 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. -- Friedrich W. H. Kossebau // KO GmbH http://kogmbh.com/legal/