incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael MacFadden <michael.macfad...@gmail.com>
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" <josephg@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.macfadden@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" <josephg@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)
>>><stenyak@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 <wave@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" <wave@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
>>
>>



Mime
View raw message