FilePath attribute is already used by S3 and HTTP protocol gateways.
Also seen in [Gaspump](https://github.com/configwizard/gaspump-api/).
Signed-off-by: Stanislav Bogatyrev <stanislav@nspcc.ru>
Define `object.Lock` message which carries list of locked objects.
Require this message to be a payload of locked objects (`LOCK` type).
Signed-off-by: Leonard Lyubich <leonard@nspcc.ru>
NeoFS introduces object LOCKs - a mechanism for locking an object from,
for example, deletion. Object locks are implemented and stored in the
container as objects, so there is a need to define a new type of system
objects.
Add `LOCK` value to `ObjectType` enum.
Signed-off-by: Leonard Lyubich <leonard@nspcc.ru>
Default string presentations of enums in protobuf are the same
as definitions. In our case it is going to be UPPER_SNAKE_CASE
string constants. Default presentation is easier to maintain.
Signed-off-by: Alex Vanin <alexey@nspcc.ru>
Neo3 Oracles need a way to check object's MIME content type, as
described in neo-project/neo-modules#555.
The proposal was to add Content-Type as a well-known attribute.
Signed-off-by: Stanislav Bogatyrev <stanislav@nspcc.ru>
All types of attribute keys must be unique and can't be repeated in the same
entity.
- Containers with duplicated attribute keys must not be accepted by InnerRing on
creation.
- Nodes with duplicated attribute keys can't be accepted to NetMap by InnerRing
- Objects with duplicated attribute keys must be considered invalid and not
accepted in PUT operations
Signed-off-by: Stanislav Bogatyrev <stanislav@nspcc.ru>
SplitInfo structure from split_info field contains meta information
to assembly the object that has been split into parts.
Signed-off-by: Alex Vanin <alexey@nspcc.ru>
In case there is a need to set flag-like attributes, the value should be set to
something like `true` or `1`.
Signed-off-by: Stanislav Bogatyrev <stanislav@nspcc.ru>
In some cases like nspcc-dev/neofs-node#167 there is no simple way to identify
where does the object part belongs to. Adding `split_id` as the required field
will simplify split object processing.
Signed-off-by: Stanislav Bogatyrev <stanislav@nspcc.ru>
NeoFS uses different checksum algorithms. It looks like we need to explicitly
define what algorithm is used in each particular case.
Signed-off-by: Stanislav Bogatyrev <stanislav@nspcc.ru>
Some pieces of data (container, object, etc) may be stored for a long time and
there will be a need in the future to understand which obscure format from the
past was used to create it.
Signed-off-by: Stanislav Bogatyrev <stanislav@nspcc.ru>
To simplify adding more transport level protocols to neofs-api-go in future, we
need to separate currently default gRPC.
Signed-off-by: Stanislav Bogatyrev <stanislav@nspcc.ru>
- Changed package names adding version
- Added documentation descriptions (sometimes useless) for all fields
- Changed enum format
- Made SessionToken and BearerToken field names more clear
Signed-off-by: Stanislav Bogatyrev <stanislav@nspcc.ru>
NeoFS Object are now Content-addressed. It means the Object's address depends on
it's content. ObjectID is now calculated as hash of Header, which contains a
hash of payload. If either if Object's payload of Headers change, the ID will
also change.
Signed-off-by: Stanislav Bogatyrev <stanislav@nspcc.ru>
Change the type of all fields for identifier of the container owner to
refs.OwnerID. This will allow you to follow a single format and not duplicate
its description.
Signed-off-by: Leonard Lyubich <leonard@nspcc.ru>
In previous version of the format storage group information was stored in
completely in the dedicated header field. However, having a header field
instead of storing it in a payload is not justified, since it is used only
to check the presence in the object. Based on this, this commit defines a
message for marking the object as the custodian of information about the
storage group and changes the type of field StorageGroup to it. Information
about the storage group will be stored serialized in the payload of the
objects marked in this way
Signed-off-by: Leonard Lyubich <leonard@nspcc.ru>
