A Wavy Future - Project Brief
Overview
Apache Wave is a successor to Google Wave -> FedOne > Wave In A Box. Wave is a real-time communication tool. Wave is a server that hosts and federates waves, supports extensive APIs, and provides a rich web client. This project aims to rewrite the original implementation of Wave that is currently available at www.github.com/apache/incubator-wave. This rewrite is to ensure a scalable and universal OT server implementation to allow Apache Wave to be used for much more than just a communication-tool that is its only service available at the time. The client implementation of the currently available tool will be extended across multiple platforms to show solutions to OT editor implementations on varying devices.
please note the project proposal for a rewrite was given here: https://docs.google.com/document/d/1YnhcupFtReZyq5Y5QheIbYFO2epEhXGucNZE04r_oA4/edit.
Server:
The Apache Wave server is to be designed as such to be a authenticated server with inbuilt data redundancy to perform OT operations on Wave data structures. Wave data structures are customised xml-like documents in which custom tags can be made to allow for differnt uses of data manipulation in this video (https://www.youtube.com/watch?v=6ZqpeFydq4A) the decisions behind the xml-like language is explained. These structures are not exclusive to the conversational structure which can be viewed here: http://wave-protocol.googlecode.com/hg/spec/conversation/convspec.html but some projects outside wave have developed additional data structures like the Swellrt project. The development of these data specifications outside the servers implementation allow for a more general use OT (operational transform) server back end and allows clients to handle the implementations. This makes the server responsible for storage, authentication and consistency only.
Client:
Note: This will address the original use of Google Wave only.
Clients for Apache wave need some level of OT implementation to accept OT instructions from the server and change the document on the clients end. The current client is deeply intertwined in the server to reduce the duplication of code for this however it limits the possibility of native implementations on other clients. The goal is to produce a Rich text multi user panel & editor to allow display of read only documents and full read/write access documents that does not know OT and a OT layer which sits below the editor. In doing this it also allows mobile clients to match the compatibility of the web client, a desktop client could also be developed if needed.
With the client wave data structure being decoupled from the server this does open up other uses for wave outside the current client which with proper levels of documentation can allow many different applications be developed on top of the Wave server.
Project Background
Note: The project background will cover most of the original implementation of Google Wave and some of the developments outside of Apache and how the project has evolved inside Apache.
Note: Basic knowledge of OT is assumed.
Project Objectives/Outcomes
Incubator Related:
The Apache Incubator is a place where young projects with basis can be further grown into top level projects at Apache, all new projects must go through the incubator before becoming top level. Most restrictions the incubator puts around graduation is about having a stable project with a community of developers and users.
- Build a community of developers and users, this is to ensure growth after the project has left the incubator and that the project doesn't lose traction.
- Have a stable source code repository.
- JIRA issues dealt with timely manner.
- Well documented, If no one can learn how to use Wave then how will it get used.
- License compliant. This refers to the legal issues with opensource licensing requirements.
Server:
- Basic Authentication.
- OAuth Authentication (Google, Facebook and so on), should we have our own OAuth server?
- REST access to Wavelets.
- REST access to User Profile.
- WebSocket protocol (Wavelets and User Profile).
- Implement wave generic OT data structures.
- Apply OT operations.
- Apply Undo OT operations.
- Search.
Client:
- Define Document Structure. (if the original spec is to be changed, this may be done to define a document type like Apache-Conversation-v1)
- Editor
- Read only mode (only cursors of editors and document updates).
- Write enabled mode.
- Note: Ace editor has been recommended as an example of a good design and api (https://ace.c9.io/#nav=about).
- Note: The editor is not to be OT aware.
- Note: The editor is to be rich text aware.
- Copy, paste, undo interactions.
- Editor-OT-Layer
- be able to translate OT operations to the editors API.
- be able to translate editor callbacks to OT operations.
- Note: All Clients must stay relatively in sync development wise though the web client will generally be the most up to date.
- Display all active wavelets for the user.
- Display unseen wavelets (or ones with updates).
- Search wave's.
Website:
These goals only refer to the website which is currently available at https://incubator.apache.org/wave/index.html.
- New Design.
- Built using a static file generator or Apache CMS.
- Include Docs onto Website (html versions).
- note: https://jacobian.org/writing/what-to-write/ describes the types of documentation which should be written.
- step-by-step tutorials.
- overviews, guides of OT and other concepts.
- reference material.
- Video tutorials.
- Wave related talk showcase page.
- Examples of Wave in the wild.
Project Depreciations
Due to Apache Wave coming from a already developed source code there are many features and other components that live within the current source. Other than the server and client there exists a few deprecated sub projects which will be addressed here:
PST Compiler:
The Protobuf String-Template compiler was used to generate json and protobuf builders for the wave project specifically. Though this project has uses outside the realm of wave and recently was separated in the source to remove it from Wave related source files in Protobuf's v3 a sub json module was implemented to reduce the need for this compiler.
Python API:
To the best knowledge of the original author of this document (Evan Hughes), I believe that the python client hasn't been functioning for some time and as such with a well made client-server API is unnecessary in the short term. Latter down the track making per language wrappers around the API would be a reasonable suggestion. As such the Python API should not be concentrated on till the server-client API is completed (or stable).