##// END OF EJS Templates
Updated the sync api document
neko259 -
r1188:d679decc decentral
parent child Browse files
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: [key-type][key][local-id]
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