Show More
@@ -1,59 +1,89 b'' | |||
|
1 | # INTRO # | |
|
2 | This document discribes the server sync protocol. | |
|
1 | # 1 Intro # | |
|
3 | 2 | |
|
4 | # PURPOSE # | |
|
3 | This document describes the server sync protocol. | |
|
4 | ||
|
5 | # 2 Purpose # | |
|
6 | ||
|
5 | 7 | This protocol will be used to share the models (currently imageboard posts) |
|
6 | 8 | across multiple servers. The main differnce of this protocol is that the node |
|
7 | 9 | can specify what models it wants to get and from whom. The nodes can get |
|
8 | 10 | models from a specific server, or from all except some specific servers. Also |
|
9 | 11 | the models can be filtered by timestamps or tags. |
|
10 | 12 | |
|
11 | # DRAFT PROTOCOL DESCRIPTION # | |
|
13 | # 3 Protocol description # | |
|
14 | ||
|
12 | 15 | The node requests other node's changes list since some time (since epoch if |
|
13 | 16 | this is the start). The other node sends a list of post ids or posts in the |
|
14 | 17 | XML or JSON format. |
|
15 | 18 | |
|
16 | 19 | Protocol version is the version of the sync api. Model version is the version |
|
17 | 20 | of data models. If at least one of them is different, the sync cannot be |
|
18 | 21 | performed. |
|
19 | 22 | |
|
20 | 23 | The node signs the data with its keys. The receiving node saves the key at the |
|
21 | 24 | first sync and checks it every time. If the key has changed, the info won't be |
|
22 | 25 | saved from the node (or the node id must be changed). A model can be signed |
|
23 | 26 | with several keys but at least one of them must be the same as in the global |
|
24 | 27 | ID to verify the sender. |
|
25 | 28 | |
|
26 | 29 | Each node can have several keys. Nodes can have shared keys to serve as a pool |
|
27 | 30 | (several nodes with the same key). |
|
28 | 31 | |
|
29 |
Each post has an ID in the unique format: |
|
|
32 | Each post has an ID in the unique format: key-type::key::local-id | |
|
30 | 33 | |
|
31 | 34 | All requests pass a request type, protocol and model versions, and a list of |
|
32 | 35 | optional arguments used for filtering. |
|
33 | 36 | |
|
34 | 37 | Each request has its own version. Version consists of 2 numbers: first is |
|
35 | 38 | incompatible version (1.3 and 2.0 are not compatible and must not be in sync) |
|
36 | 39 | and the second one is minor and compatible (for example, new optional field |
|
37 | 40 | is added which will be igroned by those who don't support it yet). |
|
38 | 41 | |
|
39 | 42 | Post edits and reflinks are not saved to the sync model. The replied post ID |
|
40 | 43 | can be got from the post text, and reflinks can be computed when loading |
|
41 | 44 | posts. The edit time is not saved because a foreign post can be 'edited' (new |
|
42 | 45 | replies are added) but the signature must not change (so we can't update the |
|
43 | 46 | content). The inner posts can be edited, and the signature will change then |
|
44 | 47 | but the local-id won't, so the other node can detect that and replace the post |
|
45 | 48 | instead of adding a new one. |
|
46 | 49 | |
|
47 | # REQUESTS # | |
|
48 | Request types: | |
|
49 | * pull - pull the desired model ids | |
|
50 | * get - get models by ids | |
|
51 | * put - give a model to the given node (you have no guarantee the node takes | |
|
52 | it, consider you are just advising the node to take your post. This request | |
|
50 | ## 3.1 Requests ## | |
|
51 | ||
|
52 | There is no constraint on how the server should calculate the request. The | |
|
53 | server can return any information by any filter and the requesting node is | |
|
54 | responsible for validating it. | |
|
55 | ||
|
56 | The server is required to return the status of request. See 3.2 for details. | |
|
57 | ||
|
58 | ### 3.1.1 pull ### | |
|
59 | ||
|
60 | "pull" request gets the desired model id list by the given filter (e.g. thread, tags, | |
|
61 | author) | |
|
62 | ||
|
63 | ### 3.1.2 get ### | |
|
64 | ||
|
65 | "get" gets models by id list | |
|
66 | ||
|
67 | ### 3.1.3 put ### | |
|
68 | ||
|
69 | "put" gives a model to the given node (you have no guarantee the node takes | |
|
70 | it, consider you are just advising the node to take your post). This request | |
|
53 | 71 | type is useful in pool where all the nodes try to duplicate all of their data |
|
54 | 72 | across the pool. |
|
55 | 73 | |
|
56 | # RESPONSES # | |
|
57 | * not supported - request is not supported | |
|
58 | * success - request was successfull | |
|
59 | * error - unexpected error | |
|
74 | ## 3.2 Responses ## | |
|
75 | ||
|
76 | ### 3.2.1 "not supported" ### | |
|
77 | ||
|
78 | If the request if completely not supported, a "not supported" status will be | |
|
79 | returned. | |
|
80 | ||
|
81 | ### 3.2.2 "success"" ### | |
|
82 | ||
|
83 | "success" status means the request was processed and the result is returned. | |
|
84 | ||
|
85 | ### 3.2.3 "error" ### | |
|
86 | ||
|
87 | If the server knows for sure that the operation cannot be processed, it sends | |
|
88 | the "error" status. Additional tags describing the error may be <description> | |
|
89 | and <stack>. |
General Comments 0
You need to be logged in to leave comments.
Login now