Show More
@@ -1,14 +1,17 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. |
@@ -26,7 +29,7 b' ID to verify the sender.' | |||
|
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. |
@@ -44,16 +47,43 b' content). The inner posts can be edited,' | |||
|
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