mirror of
https://github.com/scottlamb/moonfire-nvr.git
synced 2024-12-28 16:15:56 -05:00
dd66c7b0dd
Besides being more clear about what belongs to which, this helps with docker caching. The server and ui parts are only rebuilt when their respective subdirectories change. Extend this a bit further by making the webpack build not depend on the target architecture. And adding cache dirs so parts of the server and ui build process can be reused when layer-wide caching fails.
102 lines
4.5 KiB
Protocol Buffer
102 lines
4.5 KiB
Protocol Buffer
// This file is part of Moonfire NVR, a security camera network video recorder.
|
|
// Copyright (C) 2018 The Moonfire NVR Authors
|
|
//
|
|
// This program is free software: you can redistribute it and/or modify
|
|
// it under the terms of the GNU General Public License as published by
|
|
// the Free Software Foundation, either version 3 of the License, or
|
|
// (at your option) any later version.
|
|
//
|
|
// In addition, as a special exception, the copyright holders give
|
|
// permission to link the code of portions of this program with the
|
|
// OpenSSL library under certain conditions as described in each
|
|
// individual source file, and distribute linked combinations including
|
|
// the two.
|
|
//
|
|
// You must obey the GNU General Public License in all respects for all
|
|
// of the code used other than OpenSSL. If you modify file(s) with this
|
|
// exception, you may extend this exception to your version of the
|
|
// file(s), but you are not obligated to do so. If you do not wish to do
|
|
// so, delete this exception statement from your version. If you delete
|
|
// this exception statement from all source files in the program, then
|
|
// also delete it here.
|
|
//
|
|
// This program is distributed in the hope that it will be useful,
|
|
// but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
// GNU General Public License for more details.
|
|
//
|
|
// You should have received a copy of the GNU General Public License
|
|
// along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
syntax = "proto3";
|
|
|
|
// Metadata stored in sample file dirs as "<dir>/meta". This is checked
|
|
// against the metadata stored within the database to detect inconsistencies
|
|
// between the directory and database, such as those described in
|
|
// design/schema.md.
|
|
//
|
|
// As of schema version 4, the overall file format is as follows: a
|
|
// varint-encoded length, followed by a serialized DirMeta message, followed
|
|
// by NUL bytes padding to a total length of 512 bytes. This message never
|
|
// exceeds that length.
|
|
//
|
|
// The goal of this format is to allow atomically rewriting a meta file
|
|
// in-place. I hope that on modern OSs and hardware, a single-sector
|
|
// rewrite is atomic, though POSIX frustratingly doesn't seem to guarantee
|
|
// this. There's some discussion of that here:
|
|
// <https://stackoverflow.com/a/2068608/23584>. At worst, there's a short
|
|
// window during which the meta file can be corrupted. As the file's purpose
|
|
// is to check for inconsistencies, it can be reconstructed if you assume no
|
|
// inconsistency exists.
|
|
//
|
|
// Schema version 3 wrote a serialized DirMeta message with no length or
|
|
// padding, and renamed new meta files over the top of old. This scheme
|
|
// requires extra space while opening the directory. If the filesystem is
|
|
// completely full, it requires freeing space manually, an undocumented and
|
|
// error-prone administrator procedure.
|
|
message DirMeta {
|
|
// A uuid associated with the database, in binary form. dir_uuid is strictly
|
|
// more powerful, but it improves diagnostics to know if the directory
|
|
// belongs to the expected database at all or not.
|
|
bytes db_uuid = 1;
|
|
|
|
// A uuid associated with the directory itself.
|
|
bytes dir_uuid = 2;
|
|
|
|
// Corresponds to an entry in the `open` database table.
|
|
message Open {
|
|
uint32 id = 1;
|
|
bytes uuid = 2;
|
|
}
|
|
|
|
// The last open that was known to be recorded in the database as completed.
|
|
// Absent if this has never happened. Note this can backtrack in exactly one
|
|
// scenario: when deleting the directory, after all associated files have
|
|
// been deleted, last_complete_open can be moved to in_progress_open.
|
|
Open last_complete_open = 3;
|
|
|
|
// The last run which is in progress, if different from last_complete_open.
|
|
// This may or may not have been recorded in the database, but it's
|
|
// guaranteed that no data has yet been written by this open.
|
|
Open in_progress_open = 4;
|
|
}
|
|
|
|
// Permissions to perform actions, currently all simple bools.
|
|
//
|
|
// These indicate actions which may be unnecessary in some contexts. Some
|
|
// basic access - like listing the cameras - is currently always allowed.
|
|
// See design/api.md for a description of what requires these permissions.
|
|
//
|
|
// These are used in a few contexts:
|
|
// * a session - affects what can be done when using that session to
|
|
// authenticate.
|
|
// * a user - when a new session is created, it inherits these permissions.
|
|
// * on the commandline - to specify what permissions are available for
|
|
// unauthenticated access.
|
|
message Permissions {
|
|
bool view_video = 1;
|
|
bool read_camera_configs = 2;
|
|
|
|
bool update_signals = 3;
|
|
}
|