@Joseph My point was - the client is not that important, and in my opinion it should be handled by improving Robot API instead of re-writing existing native client. However, the Federation issue is really important. It would be really great if you could work out an prototype and then help us to port existing code toward this prototype.
On Wed, Jun 12, 2013 at 8:52 PM, Andreas Horst <horst.andrea...@gmail.com>wrote: > 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 >
