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
