Put object version field in the begining of the object message #18

New issue

Closed

opened 2025-12-28 18:11:54 +00:00 by sami · 1 comment

sami commented

2025-12-28 18:11:54 +00:00

Owner

Originally created by @alexvanin on GitHub (Aug 26, 2020).

Originally assigned to: @realloc, @alexvanin, @cthulhu-rider, @anatoly-bogatyrev on GitHub.

Object version can be used in low-level processing when storage works with stream of raw bytes, e.g. object storage takes slice of bytes, cuts version field with some offset and then chooses appropriate unmarshaler function. To do so we should have object version field in the beginning of byte stream.

Right now object version stored in the beginning of Header message. With incompatible protocol changes, header message may be moved inside Object message, so version offset may change between different protocol implementation.

To avoid this, Object message can store version as a first field. But we should store version in Header message anyway, so it may be confusing.

Other solution -- to have an agreement to never change fields before Header in Object message.

Originally created by @alexvanin on GitHub (Aug 26, 2020). Originally assigned to: @realloc, @alexvanin, @cthulhu-rider, @anatoly-bogatyrev on GitHub. Object version can be used in low-level processing when storage works with stream of raw bytes, e.g. object storage takes slice of bytes, cuts version field with some offset and then chooses appropriate unmarshaler function. To do so we should have object version field in the beginning of byte stream. Right now object version stored in the beginning of `Header` message. With incompatible protocol changes, header message may be moved inside `Object` message, so version offset may change between different protocol implementation. To avoid this, `Object` message can store version as a first field. But we should store version in `Header` message anyway, so it may be confusing. Other solution -- to have an agreement to never change fields before `Header` in `Object` message.

sami

2025-12-28 18:11:54 +00:00

closed this issue
added the
discussion
label

sami commented

2025-12-28 18:11:55 +00:00

Author

Owner

@realloc commented on GitHub (Aug 31, 2020):

We already had in mind that Object structure will be extended by adding more headers and should not have incompatible changes. It's not likely for Object to get incompatible changes breaking Header.Version field extraction.

Let's agree to never change fields before Header in Object message and keep Version field first in the Header.

@realloc commented on GitHub (Aug 31, 2020): We already had in mind that `Object` structure will be extended by adding more headers and should not have incompatible changes. It's not likely for `Object` to get incompatible changes breaking `Header.Version` field extraction. Let's agree to never change fields before `Header` in `Object` message and keep `Version` field first in the `Header`.