Show More
@@ -1,14 +1,17 b'' | |||||
1 | # INTRO # |
|
1 | # 1 Intro # | |
2 | This document discribes the server sync protocol. |
|
|||
3 |
|
2 | |||
4 | # PURPOSE # |
|
3 | This document describes the server sync protocol. | |
|
4 | ||||
|
5 | # 2 Purpose # | |||
|
6 | ||||
5 | This protocol will be used to share the models (currently imageboard posts) |
|
7 | This protocol will be used to share the models (currently imageboard posts) | |
6 | across multiple servers. The main differnce of this protocol is that the node |
|
8 | across multiple servers. The main differnce of this protocol is that the node | |
7 | can specify what models it wants to get and from whom. The nodes can get |
|
9 | can specify what models it wants to get and from whom. The nodes can get | |
8 | models from a specific server, or from all except some specific servers. Also |
|
10 | models from a specific server, or from all except some specific servers. Also | |
9 | the models can be filtered by timestamps or tags. |
|
11 | the models can be filtered by timestamps or tags. | |
10 |
|
12 | |||
11 | # DRAFT PROTOCOL DESCRIPTION # |
|
13 | # 3 Protocol description # | |
|
14 | ||||
12 | The node requests other node's changes list since some time (since epoch if |
|
15 | The node requests other node's changes list since some time (since epoch if | |
13 | this is the start). The other node sends a list of post ids or posts in the |
|
16 | this is the start). The other node sends a list of post ids or posts in the | |
14 | XML or JSON format. |
|
17 | XML or JSON format. | |
@@ -26,7 +29,7 b' ID to verify the sender.' | |||||
26 | Each node can have several keys. Nodes can have shared keys to serve as a pool |
|
29 | Each node can have several keys. Nodes can have shared keys to serve as a pool | |
27 | (several nodes with the same key). |
|
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 | All requests pass a request type, protocol and model versions, and a list of |
|
34 | All requests pass a request type, protocol and model versions, and a list of | |
32 | optional arguments used for filtering. |
|
35 | optional arguments used for filtering. | |
@@ -44,16 +47,43 b' content). The inner posts can be edited,' | |||||
44 | but the local-id won't, so the other node can detect that and replace the post |
|
47 | but the local-id won't, so the other node can detect that and replace the post | |
45 | instead of adding a new one. |
|
48 | instead of adding a new one. | |
46 |
|
49 | |||
47 | # REQUESTS # |
|
50 | ## 3.1 Requests ## | |
48 | Request types: |
|
51 | ||
49 | * pull - pull the desired model ids |
|
52 | There is no constraint on how the server should calculate the request. The | |
50 | * get - get models by ids |
|
53 | server can return any information by any filter and the requesting node is | |
51 | * put - give a model to the given node (you have no guarantee the node takes |
|
54 | responsible for validating it. | |
52 | it, consider you are just advising the node to take your post. This request |
|
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 | type is useful in pool where all the nodes try to duplicate all of their data |
|
71 | type is useful in pool where all the nodes try to duplicate all of their data | |
54 | across the pool. |
|
72 | across the pool. | |
55 |
|
73 | |||
56 | # RESPONSES # |
|
74 | ## 3.2 Responses ## | |
57 | * not supported - request is not supported |
|
75 | ||
58 | * success - request was successfull |
|
76 | ### 3.2.1 "not supported" ### | |
59 | * error - unexpected error |
|
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