[WebODF] Proposal for solution of current memberdata needs

[Friedrich W. H. Kossebau]

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/