[WebODF] Proposal for solution of current memberdata needs

Friedrich W. H. Kossebau friedrich at kogmbh.com
Wed Nov 6 04:27:55 CET 2013


Hi Peitschie,

Am Mittwoch, 6. November 2013, 01:31:04 schrieben Sie:
> 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?

Reason for that awkward seeming solution is that with the current setup only 
clients can create a ODT file from the current state. The server in the 
Owncloud Documents solution is more or less just an opstack server. It does 
neither have the knowledge how to execute ops nor, due to that, any DOM with 
the latest state of the ODF document.
Forcing the leaving client to save is more or less a random decision. Other 
options, e.g. to have one client being responsible for saving now and then and 
passing the responsibility token off in case of leaving, seemed just more work 
to get things done ;)

> Don't they then have the opportunity to update the meta-data before then?

But how?

> 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?

When a client is asked to save the current state it has in its DOM, it would 
need to set the <dc:creator> to the name of the person whose op was the latest 
modifying op WRT to the state in its DOM.
("Latest" would be estimated by the timestamp. And yes, ensuring that 
timestamps are comparable is an open, filed issue)

> > 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.

Good :) 

> > 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!

Sure, right. Cmp. the "should" :)

> 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).

Hm, initially I thought once the server/host injects the OpRemoveMember it has 
internally, right before that, removed the member from the session, thus is 
also no longer accepting any ops from that member.

What scenario did you think of?

> > 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.

Yes, agreed. There should not be a completely hardcoded set of meta-data, only 
a minimal one. And perhaps metadata definition extension sets, so existing 
editor components and server systems can be composed as wanted, knowing that 
they speak the same metadata language :)

> > 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?

Not sure what you mean with "safely accessed and used within other 
operations"? Other than that yes, ideally no code besides the execute() of the 
ops would mess around in the data model, where the "messing around" result is 
ideally defined and not random :)

> > 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.

Fine. I myself am still not sure, might first need to see it really working :)
Always expecting the unexpected...

> 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.

As mentioned above, I hope to be able to rely on the timestamps. Though that 
will need timestamp synchronisation, which is yet to be solved, see issue #61.
Would you/anyone see a problem with that?

> 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.

Ah, good question. Indeed that name/avatar reversion would be strange, unless 
one is looking for a real time-travel, like etherpad has :)

If the undo-concept would be done in the sense of applying new ops created 
from the reversed to-undo-ops, than I guess such memberdata ops would simply 
be skipped in the selection of the ops to create counterparts for. Given that 
OT of memberdata ops against the usual real ops should be 1:1 mappings (so not 
modifying the spec), the calculus of the undo ops should not be affected by 
that. I very much hope :)

> > 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 ^_^

:)

Cheers
Friedrich
-- 
Friedrich W. H. Kossebau // KO GmbH
http://kogmbh.com/legal/


More information about the WebODF mailing list