pebble/src/idl/nanopb/payload.proto
2025-01-27 11:38:16 -08:00

49 lines
1.9 KiB
Protocol Buffer

// Copyright 2024 Google LLC
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
/**
Payloads are how data should be sent and collected from devices. A simple
normal flow would be for a watch to generate Events and Measurements,
bundle them into a Payload that is sent to mobile. Mobile would then take that
payload, as well as events and measurements generated on the mobile device
itself, and bundle them into it's own Payload message to send to the
Pipeline API
More complex patterns occur when the watch sends mupltiple Payloads, at
different times, to the mobile before it gets a chance to send the data on to
the web, or if multiple devices are connected simultaneously to one mobile
device.
*/
syntax = "proto2";
package pebble.pipeline;
option java_package = "com.getpebble.pipeline";
import "common.proto";
import "event.proto";
import "measurements.proto";
message Payload {
required Tier sender = 2; /// Tier info represents who is sending a message. Payloads are uniquely identified by sender and time
required uint32 send_time_utc = 3; /// latest send attmpt time
optional uint32 send_retry_count = 4;
optional User user = 6; /// User info apply to all sub-messages contained
repeated bytes payloads = 10; /// recursive payloads form a tree structure to store arbitrary message history efficiently
// base analytics types function as tree leaves
repeated Event events = 11;
repeated MeasurementSet measurement_sets = 12;
}