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. -J On Sun, Jun 23, 2013 at 3:24 PM, Michael MacFadden <michael.macfad...@gmail.com> 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 > http://www.macfadden.org
