[WebODF] Proposal for solution of current memberdata needs

[Philip Peitsch]

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

3. Do we support the same user connecting to the same session
multiple times simultaneously? I suspect the answer to that is 
"depends on the server"… but just so people are clear that
1 person may have 1 or more members in a single document :)