Bruno,
Yes and know. The current federation protocol essential simulates only 1 server. When a client connects to a wave server that is not the server where the wave originates, that server forwards ALL operations to the authoritative wave server (the one that created the wave). All OT actually happens at this single server. The problem is that if this server goes offline, no one can edit the wave. However, in this case, it doesn't matter how many wave servers are involved, still no context vector. I would like to explore allowing servers to behave like peers. In this case, then we may run in to the problem you mention. However there are two things to consider. 1) we can apply other P2P techniques to solve this problem and 2) the servers would now be maintaining the context vector between them while federating, which insulates the clients from having to deal with the context vector themselves. ~Michael On 6/12/13 5:47 PM, "Bruno Gonzalez (aka stenyak)" <sten...@gmail.com> wrote: >On Wed, Jun 12, 2013 at 6:38 PM, Michael MacFadden < >michael.macfad...@gmail.com> wrote: > >> Purely P2P OT is potentially infeasible for collaborations that are >> extremely long live and that have large numbers of collaborators. I >> included some rationale below. >> >> [...] > >> Like I said this is an oversimplification. The real scenario is >>actually >> worse. For better or worse, Wave's algorithm was designed to remove >>this >> issue. >> > >Do you mean wave was designed to remove this issue... by having servers >(instead of P2P)? > >In that case, would the problem still persist if the amount of federated >servers (instead of users) involved in concurrently editing the same >document gets large enough? >(e.g. instead of 200 users spread over 5 federated servers, 200 users >spread over 150 federated servers) > >-- >Saludos, > Bruno González > >_______________________________________________ >Jabber: stenyak AT gmail.com >http://www.stenyak.com
