Skip to main content

Draft Protocol Spec ‎(Google Wave Federation Protocol)‎

Popularity Report

Total Popularity Score: 0
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...

Rank

Related Lists

Bookmark History

Saved by 6 people (0 private), first by anonymouse user on 2009-05-29


Public Sticky notes

A wave consists of XML documents

Highlighted by kenyth

wave addresses which consist of a user name and a wave provider domain in the same form as an email address, namely <username>@<domain>.

Highlighted by kenyth

While the root conversation wavelet of any wave should be located on the WSP indicated through parsing of the wave ID (ala '<domain>:w/<id>', e.g. 'gwave.com:w/fXd23kLp'), further wavelets inside a wave may be hosted on any WSP. The most obvious reasoning for this choice is that a user should primarily contain data - that may only be most relevant to them - within their own WSP. This is most notably the case in terms of private replies, which allow a subset of wave participants to interact privately within the already visualised wave. Private wavelets may also be used for internal participant storage; for example, to store information about what parts of a wave this user has already read.

Highlighted by enkerli

on 2009-06-04 by enkerli

Clarifies a lot, to me. Wavelets are easy to conceptualize.

A gateway translates between waves and other communication and sharing protocols such as email and IM.

Highlighted by kenyth

2.2.  Documents

Each wavelet is a container for any number of uniquely named XML documents. This set of documents are authoritatively located on the WSP that provides the given wavelet, and can not span between providers or be rehomed into alternative wavelets. To support this idiom, any single document operation may only target a single wavelet. The actions within this operation may optionally effect a single part of the contained set, but can not effect documents outside the target wavelet.

For background, however, a wavelet will contain a root document along with potentially any number of other documents arranged in a heirarchical-like conversation structure

Highlighted by enkerli

on 2009-06-04 by enkerli

Flexible enough but clear bounds.

Each wavelet has a list of participants, and a set of documents that make up its contents.

Highlighted by kenyth

A wave consists of a set of wavelets.

Highlighted by kenyth

different users have different wave views for a given wave.

Highlighted by kenyth

the user's read/unread state for the wave, is stored in a user-data wavelet in the wave with the user as the only participant.

Highlighted by kenyth

a private reply within a wave, which is represented as a wavelet

Highlighted by kenyth

A wavelet has a wavelet id which is unique within its wave.

Highlighted by kenyth

A wavelet is hosted by the wave provider of the participant who creates the wavelet.

Highlighted by kenyth

Wavelets in the same wave can be hosted by different wave providers.

Highlighted by kenyth

user-data is not federated

Highlighted by kenyth

Each wavelet is a container for any number of documents.

Highlighted by kenyth

It is composed of an XML document and a set of annotations.

Highlighted by kenyth

Annotations are key-value pairs

Highlighted by kenyth

The blips in a wave form a threaded conversation.

Highlighted by kenyth

The central pieces of the wave service is the wave store, which stores wavelet operations, and the wave server, which resolves wavelet operations by operational transformation and writes and reads wavelet operations to and from the wave store.

Highlighted by kenyth

The wave server is responsible for processing the wavelet operations submitted to the wavelet by local participants and by remote participants from other wave providers.

Highlighted by kenyth

a wave provider is "upstream" relative to its local wavelets and that it is "downstream" relative to its remote wavelets.

Highlighted by kenyth

The wave service uses two components for peering with other wave providers, a "federation host" and a "federation remote".

Highlighted by kenyth

The federation host maintains (in persistent storage) a queue of outgoing operations for each remote domain. Operations are queued until their receipt is acknowledged by the receiving federation remote.

Highlighted by kenyth

It is used to push new wavelet operations applied to a local wavelet to the wave providers of any remote participants.

Highlighted by kenyth

<wavelet-update xmlns="http://waveprotocol.org/protocol/0.2/waveserver"

Highlighted by kenyth

<delta-history xmlns="http://waveprotocol.org/protocol/0.2/waveserver"

Highlighted by kenyth

<applied-delta xmlns="http://waveprotocol.org/protocol/0.2/waveserver">

Highlighted by kenyth

<submit-request xmlns="http://waveprotocol.org/protocol/0.2/waveserver">

Highlighted by kenyth

mark-up of a ranged annotation

Highlighted by grahamperrin

documentstartannotation

Highlighted by grahamperrin

extension to XML used within the Google Wave Federation Protocol

Highlighted by grahamperrin

may span across normal XML tag boundaries

Highlighted by grahamperrin

documentendannotation

Highlighted by grahamperrin

<submit-response xmlns="http://waveprotocol.org/protocol/0.2/waveserver"

Highlighted by kenyth

the operation does not modify the input document

Highlighted by kenyth

A document is a sequence of items, where each item is a character, a start tag, or an end tag. Each item has a key-value map of annotations.

Highlighted by kenyth

After the final component, the annotations update must be empty, and the cursor must be to the right of the last item in the input document.

Highlighted by kenyth

A document operation is a set of instructions that specify how to process an input document, reading its sequence of items from left to right, to generate an output document.

Highlighted by kenyth