I think there are a lot of people using GWT; just have a look at the activity in the group.
I always wanted to participate more in Wave and it's future but TBH, discarding Java and GWT will drastically reduce my interest... Just my 2c 2013/6/12 Joseph Gentle <jose...@gmail.com> > Really? With the exception of google, I don't know of anyone who still > uses GWT. The web is mostly moving to plain javascript. Amongst other > things, a javascript web client would let us take the slow GWT > compiles out of the edit-run loop. It would also run faster & be > easier to optimize, it would let us use all the great frontend JS > libraries that are around now and be more attractive to other > developers. Oh, and it would dramatically reduce the client side JS > download. > > -J > > On Wed, Jun 12, 2013 at 10:32 AM, Yuri Z <vega...@gmail.com> wrote: > > 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 > >> > > >> > > >> > -- Andreas Horst Heinrichsallee 21, 52062 Aachen +49 170 4162251
