incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joseph Gentle <>
Subject Re: [DISCUSS] Apache Wave Sub Committees
Date Sun, 23 Jun 2013 23:54:02 GMT
These are the steps I think we should take around the new federation protocol:

1a. Figure out a p2p-capable OT algorithm & design that we're all
happy with. Make an in-process proof-of-implementation & randomizer to
convince myself its correct & not horrendously slow.

1b. Decide what data structure we want for waves. (See thread: 'A Very
Wavey Plan')

2. Implement (1) in a way that allows two processes to share a
document via OT. This will require figuring out a really simple
unauthenticated federation protocol. I expect to first get this
working for plaintext documents, then swap over to the wave data model
once we have decided on a data model and written transform (&etc)
functions for it.

3. Decide what kind of encryption to use for operations & documents, if any.

4. Either / both of:
- Port the new code & concepts to WIAB.
- Add encryption, access control and a database to the proof of
implementation written in step 2. (I want a second compatible
implementation of wave written in !java)

For OT, we need to deep dive on algorithms with people who are well
read & know our options. For that, it would make sense to have a
working group to define the problem & discuss solutions. But when it
comes to actually coding it, I don't actually want input from
non-contributors. If etting your permission will only slow us down.

I guess the advantage of forming groups around the other issues is
that it gives people autonomy around making decisions and changes.
However, I worry that if committee groups aren't made up of actual
contributors, they'll simply add another hoop for contributors to jump
through before making meaningful changes to the code. Eg, if Ali and
Yuri decided they didn't like GYP, they shouldn't need permission from
anyone to fix it. And I also don't want non-committers telling them
not to.

So I guess, I'm happy to form committees so long as their purpose is
to move the project forward, not simply make recommendations for other
people to implement.


On Sun, Jun 23, 2013 at 3:24 PM, Michael MacFadden
<> wrote:
> Wavers,
> Apache is an open community and a do-ocracy. We don't have a hierarchical structure and
anyone is welcome to contribute in any way they wish.  This is a key principle of being an
Apache project.
> At the same time we need to start to have focus in several key areas in order to progress.
As such I am recommending we for sever committees with focused topics of discussion, specific
goals, and plans of action. The committees are not intended to be exclusive in any manor.
Discussion will happen on the dev list where everyone is welcome to participate. Rather the
point of the committee is to give some focus to a group of developers who agree to help advance
particular aspects of Apache Wave.  These members would commit to facilitating discussion
on certain aspects of wave.
> I propose we form four committees based on my observation of the wave project.
> 1. Operational Transformation
> Research and design of OT algorithms, data models, and concurrency control.
> 2. Protocols
> Investigate protocols such as federation, client server, and the underlying mechanisms
such as protocol transport and discovery.
> 3. Development, Build (eg maven) and Release
> This committee would focus on making wave easier to develop, build, and release. This
can include documentation, architecture diagrams, maven, git, etc. this will hopefully help
attract developers to the project.
> 4. Client / Server Architecture
> This last group would leverage the work of the first three to start to separate the client
and server components.
> The vision would be that the committees would start holding regular discussions and start
to document plans and decisions in sections of the wiki.
> I would like your thoughts on the formation of committees, if we have the right ones
identified, and if there is interest in supporting this model.
> Regards,
> Michael MacFadden

View raw message