On Wed, Jun 12, 2013 at 7:32 PM, 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.
+1 on helping people to create their own clients. But having a basic client on hand would be great. I would not use GWT for that, as it is not so widely spread. You reach most client developers with JavaScript these days, not with GWT. Following the recent trends I would think JS + AngularJS should make a good thing. Benefit on Angular: you can create re-usable components. People can use them when they start with their own client, and later replace them one by one. I also would not underestimate the power of a client, as it should demonstrate how easy it is to use the server. > > > 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 >> > >> > >> -- http://www.grobmeier.de https://www.timeandbill.de
