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 >> >> >> >> >> > >> >> >>
