I actually like GWT in general and the fact that it allows to re-use the same OT code both on the server and client. Moreover, I think that the client is not that important, we just need to provide better Robot API and let people create their own clients.
On Wed, Jun 12, 2013 at 8:22 PM, Joseph Gentle <jose...@gmail.com> wrote: > Regardless of where the code goes, as I've said we should redesign the > OT system using proper TP2 types. This will enable us to build a > working federation protocol thats better anyway. I also think we > should separate out the OT types into a library, and make the system > capable of hosting different kinds of data. > > I don't think it makes sense to prototype that inside the WIAB > codebase. Lets iterate somewhere else. > > Once we have a working, federating TP2 OT container prototype, the > question is whether we should port the rest of WIAB's features to the > prototype or transplant the better federation algorithms into the > current WIAB codebase. Long term, we want multiple implementations > anyway for interoperability. > > There's a lot of opinions kicking around here considering that only > two people (Ali and Yuri) have contributed any code to WIAB in the > last 3 months[1]. And it sounds like Ali wants to delete a bunch of > the crap in WIAB and put it there. > > I much prefer writing javascript over java. What do you guys think > about dropping GWT and slowly porting the client to native JS? It > sounds like we want to keep the current code base anyway but separate > out the client code. Maybe once we have a prototype working, I should > start porting the client side java into nice, clean javascript. > Because GWT compiles to JS anyway, we can do this incrementally. I'd > like to do the prototype in JS or Coffee anyway, so we'll start this > process with a JS version of the new wave OT data type and go from > there. > > -J > > [1] https://github.com/apache/wave/commits/trunk > > On Wed, Jun 12, 2013 at 2:28 AM, Michael MacFadden > <michael.macfad...@gmail.com> wrote: > > Wavers. > > > > It is a very positive sign that the Wave project has seen increase > activity > > in recent weeks. However, recent conversations point to the fact that we > > are at a decision point with Apache Wave. > > > > History > > ------- > > > > Google donated quite a bit of code to Apache for the Wave project. It is > > somewhat functional and is what the community is using to drive towards a > > release. However, the current community has little expedience with the > code > > base. We didn't designed it and in many cases we don't understand it. > > > > As many have pointed out the code base is 1) Not easy to develop, 2) > Hard to > > learn, 3) and not modularized between the client and server. These > issues > > are hampering WiaB's adoption. > > > > Several people have suggested rewriting the codebase to separate the > server > > and client and to greatly simplify the architecture. > > > > > > > > I think as a community we need to decide what we want to do. I have put > > forth three options which I would like the community to comment on. > > > > > > 1) Keep the current code base and just push ahead. > > > > Pros: > > ----- > > - We have a functional codebase that we evolve over time. > > - Potentially graduate sooner. > > > > Cons: > > ----- > > - Hard to get new developers excited about working with the code base. > > - Poetnetially slows the evolution of a scalable architecture that > delivers > > what the community is asking for. > > > > > > 2) Ditch the current code base and start new. > > > > Pros: > > ----- > > - We can design something that meets the community needs. > > - We can simply the design from the beginning. > > > > Cons: > > ----- > > - We are very close to a release, this approach would set back future > > releases. > > > > > > 3) Keep the current code base AND start a new one. > > > > Pros: > > ----- > > - Can keep driving through the apache process. > > - We still have a working product. > > - We can start the redesign now. > > > > Cons: > > ----- > > - We barely have enough developers to maintain the current codebase. > > - If interest in the new codebase takes off, existing codebase would > > atrophy. > > > > > > Comments please. Thanks. > > > > ~Michael > > > > >
