I mean types which have a TP2-capable transform & purge functions. Same stuff I was talking about in the other thread.
-J On Wed, Jun 12, 2013 at 12:15 PM, Michael MacFadden <michael.macfad...@gmail.com> wrote: > Joseph, > > Can you clarify what you mean by "proper TP2 types". > > ~Michael > > On 6/12/13 6: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 >>> >>> > >
