Date: Tue, 19 Mar 2024 01:06:25 +0000 (UTC) Message-ID: <2073770338.52588.1710810385379@cwiki-he-fi.apache.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_52587_1185305465.1710810385378" ------=_Part_52587_1185305465.1710810385378 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
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 t= hat is currently available at www.github.com/apa= che/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.goo= gle.com/document/d/1YnhcupFtReZyq5Y5QheIbYFO2epEhXGucNZE04r_oA4/edit.= p>
The Apache Wave server is to be designed as such to be a authenticated s= erver with inbuilt data redundancy to perform OT operations on Wave data st= ructures. Wave data structures are customised xml-like documents in which c= ustom tags can be made to allow for differnt uses of data manipulation in t= his video (https://www.youtube.com/watch?v=3D6ZqpeF= ydq4A) the decisions behind the xml-like language is explained. These s= tructures are not exclusive to the conversational structure which can be vi= ewed here: http://wav= e-protocol.googlecode.com/hg/spec/conversation/convspec.html but s= ome projects outside wave have developed additional data structures like th= e Swellrt project. The development of these data specifications outside the= servers implementation allow for a more general use OT (operational transf= orm) server back end and allows clients to handle the implementations. = ;This makes the server responsible for storage, authentication and consiste= ncy only.
Note: This will address the original use of Google Wave only.
Clients for Apache wave need some level of OT implementation to accept O= T instructions from the server and change the document on the clients end. = The current client is deeply intertwined in the server to reduce the duplic= ation of code for this however it limits the possibility of native implemen= tations on other clients. The goal is to produce a Rich text multi user pan= el & editor to allow display of read only documents and full read/write= access documents that does not know OT and a OT layer whi= ch sits below the editor. In doing this it also allows mobile clients to ma= tch the compatibility of the web client, a desktop client could also be dev= eloped 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 pro= per levels of documentation can allow many different applications be develo= ped on top of the Wave server.
The Apache Incubator is a place where young projects with basis can be f= urther grown into top level projects at Apache, all new projects must go th= rough the incubator before becoming top level. Most restrictions the incuba= tor puts around graduation is about having a stable project with a communit= y of developers and users.
These goals only refer to the website which is currently available at&nb= sp;https://incubator.apache.org/wave/index.html.=
Due to Apache Wave coming from a already developed source code there are= many features and other components that live within the current source. Ot= her than the server and client there exists a few deprecated sub projects w= hich will be addressed here:
The Protobuf String-Template compiler was used to generate json and prot= obuf builders for the wave project specifically. Though this project has us= es outside the realm of wave and recently was separated in the source to re= move it from Wave related source files in Protobuf's v3 a sub json module w= as implemented to reduce the need for this compiler.
To the best knowledge of the original author of this document (Evan Hugh= es), 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 wo= uld be a reasonable suggestion. As such the Python API should not be concen= trated on till the server-client API is completed (or stable).
The current Wave client and other proposals which were made back when th= e project was initially open sourced had visions of the wave's being able t= o be floating windows within the browsers tab, this implementation would im= pact the rendering capabilities of the application. If the community wants = the ability to open more than one wave within the same tab multiple columns= may be the best approach instead of these floating windows. The original c= lient also had support for gadgets which could be included into the interfa= ce, this currently isn't a priority for the core functionality so will not = be included in this project brief.
Testing and Documentation is an important part of this project as the la= ck of documentation has hindered the previous source we must learn from tho= se lessons when developing further to create a well structured and we= ll documented system. An approach to this would be a code sprint -> docu= mentation sprint cycle where features are implemented over a time period an= d after that period documentation is checked for inconsistencies and if so = updated. This is to not promote not writing documentation while developing = features (which is a need) but to make sure documentation on features does = not vanish into the void. Larger pieces of documentation generally lags beh= ind like the development of tutorials
Typescript allows the developers to use high level object orientated pri= ncipals and type safety for developing the client which then gets compiled = down to plain JavaScript. https://www.typescriptlang.org/
React is the V in MVC and is used in large projects like the atom editor= . https://facebook.github.io/react/index.html
For mobile each should be built in its own language for the platform&nbs= p;(Android: Java, Iphone: Swift), a common shared c library could also be i= ncorporated but may cause more issues than solutions.
The development of the client will lag behind the server in most cases, = as such the initial development of the client should be focused on developi= ng the panel/editor that is independent of the OT protocol layer. The OT pr= otocol layer then can be developed after the editor has matured and will be= matched with the development on the server to be able to translate OT ops = to the editors ops. The editor should not be limited to wave only related u= ses and documentation and tutorials should be provided for the editor to be= used in other examples, in essence treated as a separate entity to the pro= ject. The editor being built in house allows the project to maintain the re= ndering effects of the editor and how much memory it uses as on the wave's = final client there may be a large amount of these editors on the screen at = one time. This also allows the developers to gather skills which will be ne= eded on the mobile platforms.
Golang is a c like language which is garbage collected but features simp= le syntax and a beautiful standard library. It is built by Google and has a= large growing community. Golang also has custom built debuggers for handli= ng mutli-threading and great profiling tools.
Database: NOSQL database layer to sit below the server to store wave rel= ated data to allow for data consistency and structure, multiple db's can be= supported but two main options should be Cassandra and MongoDB.
The server implementation of features will lead the client implementatio= n to create a stable API before being implemented in the client. The server= s only concerns are data integrity, authentication and document integrity; = the database layer sitting below the server will be a nosql solution which = can support its own data integrity. Suggestions for the database layer are = Cassandra and Mongodb and a debugging file based solution which should not = be used in production for performance and integrity concerns. Authenticatio= n should be developed to allow for Basic auth and external OAuth to be able= to sit side by side or just one of the options.
Website: I (Evan Hughes) have no preference over which static website ge= nerator is used, a short explanation of some of the most popular can be fou= nd here: https://www.smashingmagazine.com/2015/11/static-website= -generators-jekyll-middleman-roots-hugo-review/.
Docs: The current docs which can be found on github (https://github.com/apache/incubator-wave-docs) uses the Restructur= ed Text Format and sphinx as the compiler. Sphinx is highly customisable an= d allows multiple outputs (pdf and html) to be generated which is a large b= enefit.
The more complex the project the more important full documentation is, w= ith a consistent approach to delivering good quality documentation future d= evelopers and users can be drawn in to the Apache Wave Project.
Apache Wave has been in incubation state for many years and consistent p= rogress needs to be made for the project to graduate from the incubator as = a top level project. Depending on the amount of active developers will deci= de the amount of progress but A 2-3 year goal of completing all above requi= rements and deliverables may be achievable.