incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Grobmeier <grobme...@gmail.com>
Subject Re: Wave Future Options
Date Wed, 12 Jun 2013 17:42:56 GMT
On Wed, Jun 12, 2013 at 7:32 PM, Yuri Z <vega113@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 <josephg@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.macfadden@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

Mime
View raw message