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 > >
