Lines Matching full:server
5 // Sync protocol for communication between sync client and server.
56 // Server implementations are obligated to preserve the contents of
59 // to update the server.
65 // client-generated ID. If the commit succeeds, the server will generate
68 // |id_string| is always the server generated ID. The original
76 // in the message. In all other situations, it is a server ID.
80 // old_parent_id is only set in commits and indicates the old server
87 // maintained by for each item. If zero in a CommitMessage, the server
89 // new server ID and an initial version number. If nonzero in a
91 // the server will use |id_string| to locate the item. Then, if the item's
92 // current version on the server does not match |version|, the commit will
93 // fail for that item. The server will not update it, and will return
111 // Before then, server implementations would maintain a unique-within-parent
126 // this item was last updated on the server. This is now equivalent
132 // instanced item. The server ensures that there is never more
138 // This variant of the tag is created by the server, so clients can't create
171 // the same parent. This value is only meaningful in server-to-client
172 // contexts; to specify a position in a client-to-server commit context,
222 // per account. The server will enforce uniqueness on this tag
227 // client_defined_unique_tag is the creator of the entity. Server defined
228 // tags are entities created by the server at account creation,
233 // b) Server tag - If server committed the item as unique
291 // field numbers of all EntitySpecifics extensions supported by the server.
295 // An opaque-to-the-client sequence of bytes that the server may interpret
299 // value previously returned by the server in an earlier GetUpdatesResponse.
302 // The opaque semantics of this field are to afford server implementations
304 // a server implementation built on top of a distributed storage service --
308 // possible if the server is allowed to embed arbitrary information in
311 // Server implementations should keep the size of these tokens relatively
313 // regardless of the number of items synchronized. (A possible bad server
320 // token mechanism can set this field in a GetUpdatesMessage. The server
326 // that the server may interpret as a hint about the location of the latest
355 // event, the server will return items of all the indicated types.
362 // The server may opt to return fewer updates than this amount, but it should
366 // Per-datatype progress marker. If present, the server will ignore
383 // This message is sent to the server to clear data. An asynchronous
384 // response is returned to the client indicating that the server has received
406 // Request to clear all Chromium data from the server
410 // The client sets this if it detects a sync issue. The server will tell it
443 // Allows the server to move-aside an entry as it's being committed.
461 // If there are more changes on the server that weren't processed during this
471 // DEPRECATED FIELD - server does not set this anymore.
475 // If present and zero, this estimate is firm: the server has no changes
482 // in this field, and present them back to the server to indicate the
488 // The server may provide a new progress marker even if this is the end of
489 // the batch, or if there were no new updates on the server; and the client
490 // must save these. If the server does not provide a |new_progress_marker|
540 // Deprecated. Remove this from the server side.
548 // A command from the server instructing the client to update settings or
551 // Time to wait before sending any requests to the server.
572 NOT_MY_BIRTHDAY = 2; // Returned when the server and client disagree on
588 // a server.
599 // TRANSIENT_ERROR is not supported. Instead, the server sends back a HTTP
605 // is meaningless to this server. This happens most typically when
