Joseph, Very good commentary! I have drafted up some ideas on a hybrid system. Actually I have seen two approaches. One uses a natively P2P protocol, which then elects super nodes to act as "servers" in highly connected clusters. At the other end of the extreme I have seen client server OT use a P2P OT between federating servers. Both of these systems have pros and cons. I do think that this has some benefit over pure P2P and pure client server architectures.
~Michael On 6/11/13 6:44 PM, "Joseph Gentle" <jose...@gmail.com> wrote: >The biggest benefit to a P2P-capable system is federation. Currently, >the wave federation algorithms create a distributed tree of servers, >and they're vulnerable to netsplits if one of the root servers goes >offline. Maintaining that tree is complex and unnecessary - there are >better algorithms we can use instead. > >I imagine most devices will (most of the time) still connect to a >single server. But if our OT system can manage P2P anyway and our >system supports OT over arbitrary JSON blobs, there's a few really >neat things we can do with that. > >So, this is something I've been wanting for ages - Imagine you're >working on a software project. You put all the source code inside a >JSON wave object and you edit it there. Because its a shared OT >document, your compiler can join in on the document and annotate your >code (live) with syntax highlighting, errors and autocomplete >suggestions. It would know at a very granular level which functions >need to be recompiled as you edit. Your unit tests could rerun >themselves automatically and mark in your source code which tests >failed and where. Its like a lego set for IDEs - your editor doesn't >have to understand your programming language, your compiler doesn't >have to know what editor you're using and where, and all the pieces >can be on whatever computers are most convenient for you. And of >course, you can pair program for free. > >You could build stuff like that on top of ShareJS today, but it would >require a centralized server - and you have to put that somewhere. If >the server is on your local machine, you can't upload the edits you're >making to another OT server (like your private wave server). If its a >remote server, you'll get terrible latency between making a change in >your editor and your compiler finding out about it. With a system that >supports P2P OT, we can make servers connect any way we want and It'll >all just work. > >-J > >On Mon, Jun 10, 2013 at 1:38 PM, Dave <w...@glark.co.uk> wrote: >> [John B - I wasn't sure where else it would be appropriate to ask this >> question, but please forward on anywhere you think it appropriate] >> >> There are many things about Wave and WIAB that I would like to see >>improved >> / changed, but based on my readings I've been content with the TP1 OT >> approach chosen by google (not that I'm even close to an expert) - even >>if >> the WIAB implementation would benefit from some love. >> >> But one of the things mentioned in the recent wave-forward hangout was >>the >> weakness in Wave's OT implementation for a required canonical version >>of a >> given wave (providing absolute ordering of changesets). Specifically, >>this >> effectively prevents 3 party P2P messaging where there isn't guaranteed >>to >> be that one canonical ordering. My understanding is that Joseph is >>playing >> with some alternative OT algorithms that are TP2, and therefore don't >> require arbitration of changeset order. This was specifically called >>out as >> an advantage to support P2P messaging and running the full stack on a >>phone. >> >> That got me thinking - why would you want to do that? What are the >>benefits >> of P2P messaging, and are there other reasons to need TP2? >> >> Most of the messaging and collaboration systems I could think of are >> client-server (some with federated servers) and Wave/WIAB support this >>with >> TP1. Most networked phone apps that I'm aware of are also >>client/server, >> and at first glance this seems a good thing - it makes addressing >>easier and >> avoids issues with intermittent connectivity. The ability to have a >>simple >> "wavelike" server (and detached clients) >> >> I suspect I'm missing something, and I wondered if I'm alone? >> >> My understanding is that technical interop between the various wave-like >> communities will need us to use the same OT alogrithm (eventually), so >> clarity on the pros/cons of keeping or changing the wave OT approach >>would >> be a good first step in that direction! >> >> Dave
