incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joseph Gentle <jose...@gmail.com>
Subject Re: Future of Apache wave [Was: Re: Advantages of P2P messaging?]
Date Tue, 11 Jun 2013 21:48:34 GMT
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