Port Brave Sync server to Rust
Use SQLite for persistence and generate Rust protobuf bindings at build time. Add Docker image support for containerized deployment. Co-Authored-By: codex <[email protected]>
This commit is contained in:
commit
28826af88d
93 files changed
+11666
No files matched your search
@@ -0,0 +1,45 @@
|
||||
// Copyright 2014 The Chromium Authors
|
||||
// Use of this source code is governed by a BSD-style license that can be
|
||||
// found in the LICENSE file.
|
||||
|
||||
// NOTE: This API is not used in Chromium anymore, but the server still needs to
|
||||
// support it for the benefit of older clients (Chrome versions up to and
|
||||
// including M80 rely on it, see crbug.com/1009361).
|
||||
|
||||
syntax = "proto2";
|
||||
|
||||
option go_package = "./sync_pb";
|
||||
|
||||
option java_multiple_files = true;
|
||||
option java_package = "org.chromium.components.sync.protocol";
|
||||
|
||||
option optimize_for = LITE_RUNTIME;
|
||||
|
||||
package sync_pb;
|
||||
|
||||
import "experiments_specifics.proto";
|
||||
|
||||
// This request allows an unauthenticated client to check the status of the
|
||||
// experiments which do not require user authentication. The status of an
|
||||
// experiment for a specific client can be determined based on the user agent
|
||||
// string and/or the client id sent in the HTTPS POST request.
|
||||
message ExperimentStatusRequest {
|
||||
// Enumerates the experiments for which the status should be returned. An
|
||||
// experiment name must be the same as one of the field names specified in
|
||||
// ExperimentsSpecifics. See sync/protocol/experiments_specifics.proto.
|
||||
repeated string experiment_name = 1;
|
||||
}
|
||||
|
||||
// Response to an experiment status request.
|
||||
message ExperimentStatusResponse {
|
||||
// Minimal time to wait before issuing another request.
|
||||
optional int32 poll_interval_seconds = 1 [default = 3600];
|
||||
|
||||
// The experiments that the client has asked for, with each experiment
|
||||
// containing exactly one experiment flag. The client can inspect the
|
||||
// embedded flag to obtain the experiment status. Note that the number of
|
||||
// experiments should be less than or equal to the number of experiment_name
|
||||
// sent in the request since it is possible that there is no experiment
|
||||
// matching an experiment_name.
|
||||
repeated ExperimentsSpecifics experiment = 2;
|
||||
}
|
||||
Reference in new issue
Block a user