Thanks Michael. I understand we will have to go through serious break and make. Current code base is actually lethal at many places for performance and scalability. Not updating UI until all operations are processed makes even the basic experience sluggish. I think we need to find a clear plan for mods. If we agree on a central bus, and define interfaces/ops exchange...can we break the individual parts as we want and not care about others? It will be much easier to do modifications if we know what can change and can be deleted without worry, as long as messages on bus or interfaces stay constant. We can then mod the OT implementation when someone else works on editor, kinda goes to Joseph's concept. Although even that sounds like a big start.
On Wed, Jun 12, 2013 at 4:27 PM, Michael MacFadden < michael.macfad...@gmail.com> wrote: > Pratik, > > Very good comments. > > 1) Personally, I think staying with Java is a good idea for the engine. > 2) The OT Core is very special purpose for the wave conversation model. > Again, personally I would like to see it moved to a generic OT model, with > adaptation to the conversation model. > 3) I am not sure we need to throw away all of the code. Rather perhaps we > should just branch and slash and burn. I am sure there are parts that > could be kept, but I think we would severely break / reorganize. > > On 6/12/13 11:52 AM, "Pratik Paranjape" <pratikparanj...@gmail.com> wrote: > > >Question is: will we be able to sustain this enthusiasm long enough to > >benefit from a clean slate? Code is in bad shape, agreed. There are better > >options available today, agreed. But considering the scope, which is not > >just OT, and but a whole platform to support services on top of > >collaborative model, do we have enough reason to throw away the whole > >code? > > > >1) Do we really need to move away from Java? We are moving fast towards > >completely multi-core world. Every important language has a port for JVM . > >Wave, no matter how you architect, is going to have a structure which will > >thrive on parallelism. What could be the reason to move away from a > >platform which has been designed and optimized for 15 years exactly for > >these kinds of projects? I love python and javascript as much as I love > >Java, hell I think javascript is cuter and python feels more at home. But > >I > >think there are clear practical considerations when it comes to platform > >choices. > > > >2) How much time will it take to actually architect and re-implement : the > >wave model, the document model, CC-OT, server federation. I don't think > >there is another OT system currently in existence which supports complex > >XML documents and arbitrarily overlapping annotations like wave does. Same > >for CC. When we say we will redo, we will have to think about efforts to > >preserve all these current advantages. > > > >3) If we do re-implement, concepts are not going to be any easier. I think > >barrier for developers have been concepts. I am sure those who are not on > >this mailing list, have not even opened the code. We will have better > >code, > >yes, but I don't think that is going to make people any smarter. > > > >I think a better way will be to insist on a loosely-coupled component > >based > >architecture connected through a message bus. the problem with the current > >code is the the tight coupling. If we manage to get a message bus working, > >everyone can use their favorite language on JVM to re-implement the part > >they like..and we will even be able to reuse the parts of code. Overtime, > >we can always provide canonical Java implementation and a reference. > > > > > >On Wed, Jun 12, 2013 at 4:00 PM, Michael MacFadden < > >michael.macfad...@gmail.com> wrote: > > > >> PP, > >> > >> I agree. I think we need to look holistically at the code base. I > >> honestly don't know what the best approach is. It sounds easy to say, > >> let's just modularize it. I am not sure the current code base makes > >>that > >> possible in any meaningful way. The code is so abstract and > >>intertwined, > >> it may take MUCH longer to modularize the code than it would to start > >>over. > >> > >> On the other hand, I am not sure that starting over is feasible either. > >> I > >> really don't know. > >> > >> ~Michael > >> > >> On 6/12/13 11:26 AM, "Paulo Pires" <pjpi...@ubiwhere.com> wrote: > >> > >> >Why not simply try to improve what we already have, by modularizing > >> >stuff, separate server from web client, documenting and providing ways > >>of > >> >people to develop their products on top of Wave? > >> >I for one am not interested at all in current web client functionality, > >> >but rather in the wave-model and OT. > >> > > >> >Also, moving things from a strong-typed language and powerful framework > >> >like Java to Python or Ruby or Node.js or whatever you believe is the > >>new > >> >kid on the block, seems a little nonsense to me. People just don't > >> >understand Wave internals and won't be able to implement it whatever > >> >technologies you choose. > >> >Also, writing things from scratch seem a little far fetched, as I doubt > >> >anyone will be able to take on that task for the medium/long term. > >> > > >> >Please don't take me wrong here, but I've seen plenty discussion like > >> >this in other big projects and the result was ultimately the same, too > >> >much talk, no code. I wouldn't like this to happen to Wave. > >> > > >> >PP > >> > > >> >On Jun 12, 2013, at 10: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 > >> >> > >> >> > >> > > >> > >> > >> > > >
