https://github.com/remotestorage/spec

remoteStorage Protocol Specification
https://github.com/remotestorage/spec

Last synced: about 1 month ago
JSON representation

remoteStorage Protocol Specification

• Host: GitHub
• URL: https://github.com/remotestorage/spec
• Owner: remotestorage
• Created: 2013-02-07T03:10:32.000Z (almost 12 years ago)
• Default Branch: main
• Last Pushed: 2024-06-18T19:13:31.000Z (6 months ago)
• Last Synced: 2024-11-04T00:32:27.340Z (about 1 month ago)
• Language: HTML
• Homepage: https://tools.ietf.org/html/draft-dejong-remotestorage
• Size: 450 KB
• Stars: 87
• Watchers: 15
• Forks: 5
• Open Issues: 37
• Metadata Files:
  • Readme: README.md
  • Changelog: CHANGELOG.md

Awesome Lists containing this project

• awesome-starred - remotestorage/spec - remoteStorage Protocol Specification (others)

README

        
# Contributing

This repository is where we keep track of the versioning of the remoteStorage spec:

    https://tools.ietf.org/id/draft-dejong-remotestorage-**.txt

If you would like to suggest a change in the remoteStorage spec, you can open an issue

on https://github.com/remotestorage/spec/issues and discuss your proposal with the spec

authors.

# Versioning

Each six months (max 185 days), the output is checked using idnits, submitted to the IETF

as an Internet Draft, and published on the apps-discuss mailing list.

Authors of remoteStorage-based apps are encouraged to use a recent version of

[remotestorage.js](https://github.com/remotestorage/remotestorage.js), which aims to

support each new spec version on the day it is released, at the latest.

Implementers of remoteStorage servers and clients are encouraged to always offer support

for the latest three versions of the spec.

Storage providers should aim to expose the *previous* version of this spec, so that app

authors have six months to update their apps before they become potentially incompatible.

The latest three versions can be thought of as 'new', 'live', and 'old'. When for instance

version 03 was published, version 02 moved from 'new' to 'live', and version 01 moved from

'live' to 'old'.

So during the six months after version `k` is published, apps should add support for the 'new'

version `k`, while still supporting 'live' version `k-1` and 'old' version `k-2`.

Storage providers should aim to switch from 'old' version `k-2` to 'live' version `k-1` as soon

as possible after version `k` is released.

More info about remoteStorage in general can be found on http://remotestorage.io/

# Build

To build a new version, run:

````

    vim build.js # edit lines 1 and 2

    node build.js

    git status

````