Здравствуйте, Sinclair, Вы писали:

_>>В случае необходимости в версионирование на уровне формата данных (обычно это происходит, когда протокол общения написан не нами) второй вариант кажется заметно лучше, т.к. является не зависимым от самого формата данных (одно и тоже поле version может быть и в JSON и в MessagePac и в XML и где угодно).
S>Ну так проблема в некотром роде в том, как определяется порядок полей. Например, XML схема — штука жёсткая, в ней порядок потомков узла строго фиксирован.
S>Поэтому если мы написали, что тег <version> первым идёт в теге <message>, то так оно и будет — и мы можем на это рассчитывать. И любой способ чтения XML — хоть через DOM, хоть sax, хоть XPath — корректно вынут версию из документа, в который сложили дополнительный контент.
S>А в расте как-то гарантируется порядок обхода полей структуры?
S>Не получится случайно так, что в версии 2 на том месте, где были байты поля "версия", оказались байты поля "длина текста", а версия уехала в хвост?
S>Ведь тогда читатель, полагающийся на фиксированное расположение байтов, прочтёт мусор.

В Rust'е порядок обхода определяется по AST, которое генерирует компилятор на основе соответствующего кода и передаёт как параметр синтаксическому макросу (https://github.com/serde-rs/serde/blob/master/serde_derive/src/internals/ast.rs#L183). Очевидно, что это не плавающая упорядоченность.

_>>Но помимо этого возможно версионирование на уровне протокола (когда при происходит договорённость о версии в момент соединения). Это позволяет получить все плюсы явного версионирования, избежав при этом оверхеда на передачу и проверку версии в каждом сообщение.
S>Для этого должно быть версионирование на уровне протокола.

Если протокол свой, то это делается элементарно.

Здравствуйте, alex_public, Вы писали:

_>В Rust'е порядок обхода определяется по AST, которое генерирует компилятор на основе соответствующего кода и передаёт как параметр синтаксическому макросу (https://github.com/serde-rs/serde/blob/master/serde_derive/src/internals/ast.rs#L183). Очевидно, что это не плавающая упорядоченность.

Что и следовало ожидать — удаление поля из середины или изменения порядка полей ломает всю сериализацию

_>Если протокол свой, то это делается элементарно.

При использовании сторонних генераторов, пусть будет не Protobuf с которым у тебя что-то не срослась, а что-то более быстрое и компактнее, эта проблема решается из коробки. А для большого проекта над которым работают разные команды это серьёзная проблема. Я понимаю что для той примитивщины над которой ты работаешь это не критично, но у взрослых дядей оно так

Здравствуйте, kaa.python, Вы писали:

_>>В Rust'е порядок обхода определяется по AST, которое генерирует компилятор на основе соответствующего кода и передаёт как параметр синтаксическому макросу (https://github.com/serde-rs/serde/blob/master/serde_derive/src/internals/ast.rs#L183). Очевидно, что это не плавающая упорядоченность.
KP>Что и следовало ожидать — удаление поля из середины или изменения порядка полей ломает всю сериализацию

Ужас то какой))) А если удалить параметр или изменить их порядок в вызове любой функции ОС АПИ, то вообще приложение вылетит с непредсказуемой ошибкой. Надо срочно переделать все ОС АПИ и т.п. на Protobuf!

Да, и кстати особо забавна твоя "последовательность" в дискуссии. То мы яростно обсуждали пользу наличия версионности, то резко забываем про её существование.

_>>Если протокол свой, то это делается элементарно.
KP>При использовании сторонних генераторов, пусть будет не Protobuf с которым у тебя что-то не срослась, а что-то более быстрое и компактнее, эта проблема решается из коробки. А для большого проекта над которым работают разные команды это серьёзная проблема. Я понимаю что для той примитивщины над которой ты работаешь это не критично, но у взрослых дядей оно так

Если под взрослыми дядями ты подразумеваешь классический энтерпрайз (т.е. решение стандартных задач огромной толпой дешёвых специалистов), то я действительно таким никогда не занимался и не планирую. Я предпочитаю обитать в области инноваций (где решают сложные задачи маленькой командой за большие деньги). Но это всё уже глубокий оффтопик...