Hello Wiab! During the year Andrew Kaplanov & Denis Konovalchik implemented new structure of data store, protocol and renderer to accelerate big waves opening.
We have already deployed to wiab.pro: Renderer: - dynamic rendering only visible screen area - highlighting of deleted blips New protocol: - opening the wave with displaying changes since previous opening - reopening the wave after connection is lost - error diagnostics We're going to deploy to wiab.pro soon: Data store: - creation of snapshots and operation history for requested documents (for blips in the visible area) - operation aggregation during writing - data deserialization only when it's necessary New protocol: - uploading blips into visible area - data deserialization only when it's necessary We support our own wiab.pro instance and would be glad if Apache Wiab placed the link to wiab.pro as a commercially supported demo-server onto http://incubator.apache.org/wave/index.html page. In this case we could be a company supporting and coordinating the development and we would commit more into the official repository. Does anybody have some plans? It would be nice to avoid duplicating our implementation efforts. On Tue, Mar 24, 2015 at 7:49 PM, Yuri Z <vega...@gmail.com> wrote: > I can share my own roadmap - or things I would do. > > 1. Modernization > 1.1 Replace GXP templating system that is used to generate few front end > HTMLs with something that is main stream and well documented. > 1.2 Replace ant scripts that are used to build the project/manage > dependencies with something else - like Maven, Gradle or SBT. I personally > don't like maven and prefer more modern build systems like gradle/sbt. > 1.3 Replace the system configuration framework that is custom written > Google thing with something more standard. It would be nice to replace > server.config and custom annotations with Typesafe Config. > > 2. Rewrite of the concurrency handling. The current concurrency handling > code is buggy and really complex. Some of it uses locks for > synchronization, some is asynchronous with callbacks and some works with > Guava futures. Parts of it were written for Google Wave but most was hacked > for FedOne and later for Wiab. I think this particular logic can be greatly > simplified if re-written using the Akka Actors framework. In Java or > preferably in Scala (that's why I prefer SBT over Gradle). > > 3. Re-think how we should solve the tight coupling/great complexity of > client-server protocol. Maybe we should split the Wiab project into two > parts server and client - where server will depend on compiled javascript > client. > > > > > > On Tue, Mar 24, 2015 at 1:12 PM Christian Grobmeier <grobme...@apache.org> > wrote: > > > we have volunteers for the next months. Why not discussing what we > > should do? > > > > My first preference would be: craft a release. > > I forgot what was missing back then, but it would be great to find out > > from the mail archives and create jira issues for the open things. Maybe > > Ali could help here, as he was the RM for the last try. > > > > The next thing would maybe be more technical. Can you throw in some > > concrete ideas what could be achieved in small steps? > > I guess "refactoring everything" is not a good start :) > > > > Regards, > > > > Christian > > >
