No this was just a little side project I did to research OT. It was completely outside of WAVE just a little java POC. It was throw away code to help me wrap my brain around the algorithm.
On 6/11/13 10:48 PM, "Joseph Gentle" <jose...@gmail.com> wrote: >Where abouts? In WIAB itself? (I haven't looked at the codebase in awhile) > >-J > > >On Tue, Jun 11, 2013 at 2:44 PM, Michael MacFadden ><michael.macfad...@gmail.com> wrote: >> 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 >> >>
