gergely/taskwarrior-2.x
1
0
Fork 0
Code Issues Actions Packages Projects Releases 1 Wiki Activity

eliminate unnecessary backslash-escaped quotes

Browse Source
This commit is contained in:
Dustin J. Mitchell
2022-04-21 01:17:38 +00:00
committed by Tomas Babej
parent b1ca5d4cf8
commit 18e11300fd
14 changed files with 116 additions and 116 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
docs/rfcs/client.md
View File

@@ -23,7 +23,7 @@ The client will need proper credentials to talk to the server.
In this document, we adopt the convention discussed in Section 1.3.2 of [RFC1122](https://tools.ietf.org/html/rfc1122#page-16) of using the capitalized words MUST, REQUIRED, SHOULD, RECOMMENDED, MAY, and OPTIONAL to define the significance of each particular requirement specified in this document.
In brief: \"MUST\" (or \"REQUIRED\") means that the item is an absolute requirement of the specification; \"SHOULD\" (or \"RECOMMENDED\") means there may exist valid reasons for ignoring this item, but the full implications should be understood before doing so; and \"MAY\" (or \"OPTIONAL\") means that this item is optional, and may be omitted without careful consideration.
In brief: "MUST" (or "REQUIRED") means that the item is an absolute requirement of the specification; "SHOULD" (or "RECOMMENDED") means there may exist valid reasons for ignoring this item, but the full implications should be understood before doing so; and "MAY" (or "OPTIONAL") means that this item is optional, and may be omitted without careful consideration.
## Taskserver Account
@@ -50,12 +50,12 @@ An example of this value is:
In addition to a DNS name, this can be an IPv4 or IPv6 address.
The organization name is an arbitrary grouping, and is typically \'PUBLIC\', reflecting the individual nature of server accounts.
The organization name is an arbitrary grouping, and is typically 'PUBLIC', reflecting the individual nature of server accounts.
Future capabilities will provide functionality that support groups of users, called an organization.
The user name is the full name.
This will be the name used to identify other users in an organization, in a future release.
Example \'John Doe\'.
Example 'John Doe'.
The password is a text string generated by the server at account creation time.
It should be considered a secret.
@@ -93,12 +93,12 @@ The client may use any library that supports the above.
## Configuration
The client needs to store configuration, which matches the credentials needed for Taskserver communication.
See section 2.1 \"Credentials\".
See section 2.1 "Credentials".
The credentials may not be modified by the user without losing server access.
The server:port data may need to be changed automatically following a redirect response from the server.
See section 5 \"Server Errors\".
See section 5 "Server Errors".
## Local Storage
@@ -121,7 +121,7 @@ If a client performs too many sync operations, the server MAY revoke the certifi
Effectively, the client should maintain a separate list of tasks changed since the last successful sync operation.
Note that tasks have a \"modified\" attribute, which should be updated whenever a change is made.
Note that tasks have a "modified" attribute, which should be updated whenever a change is made.
This attribute contributes to conflict resolution on the server.
@@ -129,7 +129,7 @@ This attribute contributes to conflict resolution on the server.
When a server sends remote changes to a client, in the response to a sync request, the changes have already been merged by the server, and therefore the client should simply store them intact.
Based on the UUID in the task, the client can determine whether a task is new (and should be added to the local list of tasks), or whether it represents a modification (and should overwrite it\'s existing entry).
Based on the UUID in the task, the client can determine whether a task is new (and should be added to the local list of tasks), or whether it represents a modification (and should overwrite it's existing entry).
The client MUST NOT perform any merges.
@@ -145,11 +145,11 @@ If a client omits the sync key in a sync message, the response will be a complet
## Data Integrity
Although a task is guaranteed to contain at least \'entry\', \'description\' and \'uuid\' attributes, it may also contain other known fields, and unknown user-defined fields.
An example might be an attribute named \'estimate\'.
Although a task is guaranteed to contain at least 'entry', 'description' and 'uuid' attributes, it may also contain other known fields, and unknown user-defined fields.
An example might be an attribute named 'estimate'.
If a task is received via sync that contains an attribute named \'estimate\', then a client has the responsibility of preserving the attribute intact.
If that data is shown, then it is assumed to be of type \'string\', which is the format used by JSON for all values.
If a task is received via sync that contains an attribute named 'estimate', then a client has the responsibility of preserving the attribute intact.
If that data is shown, then it is assumed to be of type 'string', which is the format used by JSON for all values.
Conversely, if a client wishes to add a custom attribute, it is guaranteed that the server and other clients will preserve that attribute.
@@ -170,7 +170,7 @@ The response message contains status and remote changes, which MUST be stored lo
## Establishing Encrypted Connection
All communication with the Taskserver is encrypted using the certificate and key provided to each user.
Using the \'server\' configuration setting, establish a connection.
Using the 'server' configuration setting, establish a connection.
## Sync Request
@@ -182,7 +182,7 @@ A sync request MUST contain a list of modified tasks, in JSON format (see [Task
## Sync Response
A sync response WILL contain a \'code\' and \'status\' header variable, WILL contain a sync key in the payload, and MAY contain a list of tasks from the server in JSON format (see [Task JSON](/docs/design/task)).
A sync response WILL contain a 'code' and 'status' header variable, WILL contain a sync key in the payload, and MAY contain a list of tasks from the server in JSON format (see [Task JSON](/docs/design/task)).
## Server Messages
@@ -227,7 +227,7 @@ All errors consist of a code and a status message:
Here are examples of properly formatted request and response messages.
Note that the messages are indented for clarity in this document, but is not the case in a properly formatted message.
Also note that newline characters U+000D are not shown, but are implied by the separate lines.
Because some messages have trailing newline characters, the text is delimited by the \'cut\' markers:
Because some messages have trailing newline characters, the text is delimited by the 'cut' markers:
foo
@@ -344,7 +344,7 @@ Note the double newline character separating header from payload, with an empty
status: Redirect
info:
Note the \'info\' field will contain a \':\' string that should be used for all future sync requests.
Note the 'info' field will contain a ':' string that should be used for all future sync requests.
This indicates that a user account was moved to another server.
Note the double newline character separating header from payload, with an empty payload.