I didn't realise that it was that messy, my apologies. If its that intertwined I agree with starting again completely.
If we take that option might be worth considering if Java is the right language. We may get more interest if we replace it with a 'cooler' language like Python or Ruby. Just my 2 cents... (from someone that programs a bit, and finds python way more accessible than java) Thanks Angus Turner angusisf...@gmail.com On Wed, Jun 12, 2013 at 7:35 PM, Michael MacFadden < michael.macfad...@gmail.com> wrote: > Angus, > > I think we all agree on that point. The question is how to do it. Try to > separate the current codebase (Option 1) or just start over (Option 2). > Trying to separate the current code base may not actually be feasible. It > MAY be quicker to just start over. I am not saying that it IS quicker to > start over, but it is possible. > > I have worked extensively with the current codebase and the server code is > strewn with GWT stuff that works directly with the UI. This goes ALL THE > WAY down into the OT core. > > So, I am not discussing what features or architectures we should focus on > first, but rather do we continue with the current code base, work on a new > codebase, or both. > > ~Michael > > On 6/12/13 10:31 AM, "Angus Turner" <angusisf...@gmail.com> wrote: > > >I think we need to separate the client from the server first of all. That > >allows things like OT and federation to be ripped out and replaced whilst > >leaving the client intact and slowly changing that if need be. > > > >Thanks > >Angus Turner > >angusisf...@gmail.com > > > > > >On Wed, Jun 12, 2013 at 7:28 PM, 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 > >> > >> > >> > > >
