Good question. Personally, I'd like to fix federation so its simpler, more reliable and easier to deploy. And if we move to a proper P2P OT system, we can get some neat new properties out of our system while we're at it.
I also think wave in a box should allow federation of multiple different OT types. At the very least, having an OT-aware JSON primitive type would be a huge win. We wanted that when wave was still being developed so gadgets could store state - but instead of making JSON a primitive type, we dodgy hacked it on top of wave's OT model. Having a JSON primitive type would let other applications be built on top of wave's infrastructure. It suggests a really nice architectural separation, where we have a federated OT system which understands users and shared data. Then on top of that, applications can exist (like wave, photoshop or an IDE) which stores & edits a user's data using this collaborative data layer, letting us collaborate on anything, with anyone, between all our devices. I think I'm still hanging out for my 'glorious messaging bus in the sky' :) -J On Tue, Jun 11, 2013 at 1:28 PM, Michael MacFadden <michael.macfad...@gmail.com> wrote: > 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 >>> >>> >> > >
