+1 for hybrid.
On Tue, Jun 11, 2013 at 11:43 PM, Pratik Paranjape < pratikparanj...@gmail.com> wrote: > Joseph. > May be I am not getting it fully, I don't see how latency problem will be > resolved in the P2P architecture you mentioned. The editor and the compiler > are still remotely connected. Even if compiler has access to it's own OT > system which builds the source files for it on every new delta, deitas will > have to travel from editor node to compiler node. Assuming compile lies on > server in a server-client system, and both editor and compiler have access > to OT, its effectively the same process, server acting as remote node. On > the other hand, editor, compiler, test-runners can still participate as > agents, irrespective of the node they are at, possibly acting as clients, > and do their respective jobs. P2P or not. > > At max, the P2P federation gives flexibility of having different blocks on > different nodes. But then, the more you distribute, the more you face the > overheads of OT processing for each block. Not saying it will be huge, but > a change from client-server for sure. > > Am I missing something? I have been working on a similar system, not > specifically OT, but given replication as a necessity, I had to conclude > client-server system has most practical advantages, including more control. > > > On Tue, Jun 11, 2013 at 11:18 PM, Michael MacFadden < > michael.macfad...@gmail.com> wrote: > >> 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 >> >> >> >
