Dave, I guess the question I would ask before going down this road is what is the problem that you are currently seeing in WIAB that you would attributed to either the OT Algorithm and/or its implementation?
What problem are we trying to solve through option 1/2? ~Michael On 6/11/13 9:25 PM, "Dave" <w...@glark.co.uk> wrote: >Cool. Thanks Michael. > >I guess the reason I'm keen to understand the pros/cons is because it >looks as though we're heading to a point where the wave community needs >to figure out the direction for Apache wave and the wiab codebase >(within appropriate [DISCUSS] and [VOTE] threads of course). Probably as >part of the larger conversation that John Blossom started. > >I'm beginning to think we're talking about two discrete directions: > >1) The wave OT or protocol are broken & not fit for purpose. We should >implement different OT and / or protocol which is (likely) incompatible >with the existing implementations. Potentially this could involve >junking the current wiab codebase, and implementing a new wave like >platform (potentially on top of existing non-wiab code). > >2) Wave OT and protocol are good-enough for our immediate / mid-term >desires, but the wiab implementations could be stronger. We want to >focus on expanding the ecosystem - enabling different clients, >simplifying federation, tidying the codebase. I.e. convert what we've >got into a useful product. > >With enough resource, maybe we could aim for Apache wave to take both >directions - expand the ecosystem now and work on long-term incompatible >changes, but given the lack of an existing install base this might not >be an ideal choice. > >Until recently, I assumed we were just heading for #2, but there's >clearly some desire for #1, and some known weaknesses in Wave's current >approach. > >Certainly OT state-of-the-art has moved on significantly since the wave >implementation, but should wave be on the bleeding edge of OT? Or are >our developers and community more focused on a slick (and feature rich) >implementation of the core technology google demo'd a few years back? > >I've got lots of questions and very few answers, but hopefully we're >getting more clarity on what we want/expect from this community. > >Dave > > >On 11/06/13 19:41, Michael MacFadden wrote: >> In a sense yes. In a P2P model there is no single canonical wave. All >> the federated servers would have a copy of the wave. Any server that >> drops out simply drops out. The isolated server could still server up >>the >> wave to its clients if it were still connected. Then when it comes >>back, >> it would rejoin the other federating servers. >> >> There are some intricacies here, but that is the main idea. >> >> ~M >> >> On 6/11/13 7:37 PM, "Dave" <w...@glark.co.uk> wrote: >> >>> On 11/06/13 18:48, Michael MacFadden wrote: >>>> 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. >>> Interesting - so this effectively would allow re-hosting of a wave if >>> the original host goes off line? >>> >>> The underlying OT supports P2P style merging, and there are the >>> efficiency advantages of having OneTrueHost for a given wave, but if >>> that host goes offline the wave can be re-hosted elsewhere. >>> >>> Dave >> >> >
