Joseph, I agree. I took wave's concept and completely redid the code base. I removed all of the wave conversation model operations and concepts and replaced them with ones that just operate on objects. The resulting codebase was much smaller, more stable, and more flexible. Granted the applications have to do a little more work to stuff their things in and out of the object model, but this puts the complexity in the right spot.
I am all for a more generic OT engine. The vast amount of literature on OT would support this architecture. ~Michael On 6/11/13 10:38 PM, "Joseph Gentle" <jose...@gmail.com> wrote: >I heard a story once from some developer attending a java conference. > >The theme was how to solve the challenges that Java faces in the next >decade - and basically everyone was talking about how to make >development tools scale up to work with codebases which were millions >of lines long. How do we manage big projects? How well does eclipse >scale? How do we refactor codebases that size? > >This is crazy. The right question isn't "How do we scale our tools", >its "How do I write less java?". > >On Tue, Jun 11, 2013 at 2:00 PM, Bruno Gonzalez (aka stenyak) ><sten...@gmail.com> wrote: >> That said, I'd be wary of replacing a 300k LOC codebase with a new >>version, >> when we are barely managing to maintain the existing code. > >This ^ is the same thing. The answer is that if we have a small >project, we wouldn't have to manage 300k lines of code. The first >version of ShareJS had working plaintext OT in about 3k LOC. I've >recently rearchitected the entire system (which necessitated changing >about 70% of the code) and it only took me 2 months. > >Simply put, I totally agree with you - we really can't afford to >maintain a 300k LOC codebase. If you ask me, replacing WIAB with a >smaller codebase isn't the dangerous way forward, its the only way >forward. > >> In any case, I wonder if making current wiab *way* more easily federable >> would in practice equate to a p2p version of wiab. I.e. modify WiaB so >> that, in the future, any luser can "aptitude install wiab" and have a >> federated server+client of wave, that can connect to other servers >>without >> any further configuration (or extremely little configuration at least; >> think BittorrentSync levels of usability, for example). Is it >>technically >> possible to make wiab work like a P2P network, or are federation/OT/... >> protocols simply not able to scale like that? > >The reason why WIAB is hard to deploy is because: >- You need a signed SSL certificate >- Federation works via an XMPP extension - so you have to install an >XMPP server and hook them together > >The deployment problems don't really have anything to do with the OT >algorithms. I'm all for some discussion around those design decisions >- the XMPP extension stuff definitely contributes to code complexity >and server flakiness. > >-J > > >> On Tue, Jun 11, 2013 at 10: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 >>>>> >>>> >>>> >>>> >>> >> >> >> -- >> Saludos, >> Bruno González >> >> _______________________________________________ >> Jabber: stenyak AT gmail.com >> http://www.stenyak.com
