Jump to content

Collaborative real-time editor

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Tedder (talk | contribs) at 17:34, 1 September 2020 (→History of key products: rm product with direct link; if notable, link to wiki article). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Not to be confused with collaborative editing.

A collaborative real-time editor is a type of collaborative software or web application which enables real-time collaborative editing, simultaneous editing, or live editing of the same digital document, computer file or cloud-stored data – such as an online spreadsheet, word processing document, database or presentation – at the same time by different users on different computers or mobile devices, with automatic and nearly instantaneous merging of their edits.

Real-time collaborative editing can occur online in web applications such as Microsoft Office on the web (formerly Office Online) – which supports online (web-based) simultaneous editing (which Microsoft refers to as "Co-Authoring") of Word documents, Excel spreadsheets, PowerPoint and other Microsoft Office documents stored on Office.com, OneDrive or SharePoint cloud storage – or Google Docs and other G Suite productivity (office suite) apps – for online collaborative editing of word processing and other documents stored in Google Drive. Real-time collaborative editing can also occur in hybrid manner, such as with Power Sheet BI for Excel[1], in offline, web-based, and online collaborative editing in desktop software as well as web-based and mobile apps, which can be synchronized automatically with instant access to version history.

Unlike asynchronous (non-real-time, delayed or offline) collaborative editing, such as occurs with revision control systems like Git or Subversion, real-time editing performs automatic, periodic, often nearly instantaneous synchronization of edits of all online users as they edit the document on their own device. This is designed to avoid or minimize edit conflicts. In asynchronous collaborative editing, each user must typically manually submit (publish, push or commit), update (refresh, pull, download or sync) and (if any edit conflicts occur) merge their edits.

Due to the delayed nature of asynchronous collaborative editing, multiple users can end up editing the same line, word, element, data, row or field resulting in edit conflicts which require manual edit merging or overwriting, requiring the user to choose which edits to use or (depending on the system and setup) automatically overwriting their edits or other people's edits, with or without a warning.

History of key products

The first instance of a collaborative real-time editor was demonstrated by Douglas Engelbart in 1968, in The Mother of All Demos. Widely available implementations of the concept took decades to appear.

Instant Update was released for the classic Mac OS in 1991 from ON Technology.[2][better source needed] Later, a version for Microsoft Windows was released as well, allowing real-time[citation needed] collaboration across these two operating systems.[citation needed] Instant Update relied on a work group server to coordinate documents updated in real time on multiple clients.

The Web 2.0 phenomenon has caused an explosion of interest in browser-based document editing tools. In particular, a product called Writely saw explosive user growth and was bought by Google in March 2006 (what became known as Google Docs and later renamed to Google Drive). It provided simultaneous edits on the entirety of a document, though changes from other users were only reflected after the client program polling the server (every half-minute or so).[citation needed] Another early web-based solution was JotSpotLive, in which line-by-line simultaneous editing was available in near-realtime.[3] However, after Google's purchase of parent company JotSpot in November 2006, the site was closed. Google Sites was launched in February 2007 as a refactoring of JotSpot,[4][5][6][7] but it lacks the multi-user real-time abilities of JotLive. The Synchroedit (rich text) and MobWrite (plain text) projects are two, more recent, open source attempts to fill the gap in real-time browser-based collaborative editing, though still unable to achieve true real-time performance, especially on a large scale architecture.[citation needed]

In 2009, Google started beta testing Google Wave, a real-time collaboration environment which Google hoped would eventually displace email and instant messaging.[citation needed] EtherPad was acquired by Google, which allocated the EtherPad team to work within the Wave project. However, Google announced in August 2010 on its blog[8] that it had decided to stop developing Wave as a standalone project, due to insufficient user adoption. After Google released the abandoned EtherPad source code as open source in December 2009, the community took over its development and produced a complete rewrite named Etherpad lite, which is written entirely in JavaScript and built on top of node.js. Other notable tools based on operational transformation technology are CKEditor, and SubEthaEdit.[9]

Technical challenges

The complexity of real-time collaborative editing solutions stems from communication latency. In theory, if communication were instantaneous, then creating a real-time collaborative editor would be no more difficult than creating a single-user editor, because a document could be edited using an algorithm similar to the following:

  1. Request an 'edit document' token from the server
  2. Wait until the server says it's our turn to edit the document
  3. Tell the server how to edit the document
  4. Release the 'edit document' token

However, the speed of communication is limited by network latency. This creates a fundamental dilemma: users need their own edits incorporated into the document instantly, but if they are incorporated instantly, then because of communication latency, their edits must necessarily be inserted into different versions of the document.

An example illustrates this problem. Suppose Bob and Alice start with a document containing the word Mary. Bob deletes 'M', then inserts 'H', to change the word into Hary. Alice, before she receives either edit from Bob, deletes 'r', then deletes 'a', to change it into My. Both Bob and Alice will then receive edits that were applied to versions of the document that never existed on their own machines.

Thus, the challenge of real-time collaborative editing is to figure out exactly how to apply edits from remote users, which were originally created in versions of the document that never existed locally, and which may conflict with the user's own local edits.

The most sophisticated solutions solve this problem in a way that does not require a server, does not use locking (all users can freely edit all parts of a document at the same time), and supports any number of users (limited only by the resources of the computers). UNA and SubEthaEdit are examples of two programs that take this approach.

While these sophisticated approaches enable the best user experience, a basic collaborative editor can also be created in a client–server model. In a client–server scenario, one of the editor instances is assigned the role of collaboration server when the document is opened. This server ensures that other editors are kept in sync by determining network latency and acting as a time synchronization server. The server receives timestamped notifications of changes made to the document by other users. It determines how those changes should affect its local copy, and broadcasts its changes to the collaboration pool. In some models, the changes are not reflected on a client until an official response is returned from the server, even if those changes were made locally.

This approach, while significantly less powerful, allows for basic collaboration at a relatively low cost. This makes it preferable in situations where processing resources are limited. NetSketch is an example of a program that uses this model.

In the past, Microsoft and IBM have worked to add collaboration facilities to their existing architectures.[10] Although marketed as real-time collaboration, these 'workspace' approaches require either document locking (so only one person can edit it at a time), or 'reconciliation' of conflicting changes, which is generally found by users to be unsatisfactory.[citation needed]

See also

References

  1. ^ "FREE No-Code App, Analytics AI, Blockchain, Excel＆Web 3.0 Collaboration Platform". PowerSheet.ai. Retrieved 2020-06-08.
  2. ^ "User manual". Archived from the original on 2009-02-21.
  3. ^ Michael Arrington (2005-09-27). "JotSpot Live — The Perfect Wiki?". TechCrunch.
  4. ^ Michael Arrington (2008-02-27). "It Took 16 Months, But Google Relaunches Jotspot". TechCrunch.
  5. ^ David Chartier (2008-02-28). "First look: Google relaunches JotSpot as Google Sites". Ars technica.
  6. ^ Dan Farber (2008-02-27). "JotSpot reincarnated as Google Sites". CNET News.
  7. ^ Mark 'Rizzn' Hopkins (2008-02-27). "Google Finally Frees JotSpot with Google Sites". Mashable.
  8. ^ Ina Fried and Josh Lowensohn (2010-08-04). "Google pulls plug on Google Wave". CNET.
  9. ^ SunChengzheng; SunDavid; NgAgustina; CaiWeiwei; ChoBryden (2020-01-04). "Real Differences between OT and CRDT under a General Transformation Framework for Consistency Maintenance in Co-Editors". Proceedings of the ACM on Human-Computer Interaction. doi:10.1145/3375186.
  10. ^ Microsoft Live Communications Archived 2008-03-05 at the Portuguese Web Archive Marketed as real time but not real time in the sense of this article.
Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Collaborative_real-time_editor&oldid=976191642"