[WebODF] Proposal for solution of current memberdata needs
Friedrich W. H. Kossebau
friedrich at kogmbh.com
Mon Nov 4 17:43:11 CET 2013
there are two operations (one existing, one hypothetical) which create/modify
datastructures with the element <dc:creator>:
* 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
<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 §18.104.22.168
<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.
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>?
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...,
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
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?
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
More information about the WebODF