incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael MacFadden <>
Subject Re: Future of Apache wave [Was: Re: Advantages of P2P messaging?]
Date Tue, 11 Jun 2013 21:51:58 GMT
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" <> wrote:

>Where abouts? In WIAB itself? (I haven't looked at the codebase in awhile)
>On Tue, Jun 11, 2013 at 2:44 PM, Michael MacFadden
><> 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" <> 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)
>>><> wrote:
>>>> That said, I'd be wary of replacing a 300k LOC codebase with a new
>>>> 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
>>>> In any case, I wonder if making current wiab *way* more easily
>>>> 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
>>>> any further configuration (or extremely little configuration at least;
>>>> think BittorrentSync levels of usability, for example). Is it
>>>> possible to make wiab work like a P2P network, or are
>>>> 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.
>>>> On Tue, Jun 11, 2013 at 10:25 PM, Dave <> 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
>>>>> appropriate [DISCUSS] and [VOTE] threads of course). Probably as part
>>>>> 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
>>>>> implement different OT and / or protocol which is (likely)
>>>>> with the existing implementations. Potentially this could involve
>>>>> 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
>>>>> on expanding the ecosystem - enabling different clients, simplifying
>>>>> federation, tidying the codebase. I.e. convert what we've got into a
>>>>> product.
>>>>> With enough resource, maybe we could aim for Apache wave to take both
>>>>> directions - expand the ecosystem now and work on long-term
>>>>> changes, but given the lack of an existing install base this might
>>>>> an ideal choice.
>>>>> Until recently, I assumed we were just heading for #2, but there's
>>>>> some desire for #1, and some known weaknesses in Wave's current
>>>>> Certainly OT state-of-the-art has moved on significantly since the
>>>>> implementation, but should wave be on the bleeding edge of OT? Or are
>>>>> 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.
>>>>>> the federated servers would have a copy of the wave.  Any server
>>>>>> 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
>>>>>> 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" <> 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
>>>>>>>> which then elects super nodes to act as "servers" in highly
>>>>>>>> clusters.
>>>>>>> Interesting - so this effectively would allow re-hosting of a
>>>>>>> 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,
>>>>>>> that host goes offline the wave can be re-hosted elsewhere.
>>>>>>> Dave
>>>> --
>>>> Saludos,
>>>>      Bruno González
>>>> _______________________________________________
>>>> Jabber: stenyak AT

View raw message