Расширяемость схем в ASN.1 придумали и стандартизировали в 1984 году. С тех пор хуже не стало, а стало даже лучше.

десять лет назад я на Thrift ругался за это: https://lionet.info/asn1c/blog/2010/07/18/thrift-semantics/

прослеживается непонимание: зачем было делать трифт, если уже есть asn

NIH (not invented here) синдром? ASN.1 сложно-сложно?

возможное объяснение
http://lurkmore.to/%D0%A4%D0%B0%D1%82%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B9_%D0%BD%D0%B5%D0%B4%D0%BE%D1%81%D1%82%D0%B0%D1%82%D0%BE%D0%BA

У меня есть подозрение что с помощью трифта планировалось собирать статистику и аналитику где каких объектов трафик. В огромной сети фейсбука это имеет смысл. И тогда к нему несколько больше требований чем сеарилизация десеарелизация

Он похож на протокол для распределеных вычислений и нужд интернет корпораций

фиг знает, вроде как тот же rpc, с кучей своих нюансов, локалхост разработчику непонятных от слова совсем

могу рассказать как в Apache Avro предлагается решать вопросы версионирования.

допустим есть схема

User {
  Int64 id,
  String name
}

мы схему опубликовали в schema registry и к каждому сообщению заголовком добавляем имя и ID схемы в schema registry. все потребители у себя её включили, скачивают схему со schema registry по id, кешируют и декодируют что мы им присылаем этой схемой. Понаписали своих Java классов с полями id и name.

мы решили ужать id до Int32 (не спрашивайте) и добавить поле surname

User {
   Int64 id,
  String name,
  String surname
}

опубликовали новую версию в Schema registry - она получила новый ID. Мы теперь его пристёгиваем к сообщениям.

Клиент при получении сообщения с новой версией скачивает новую схему и декодирует ей. Видит что там Int32 и кастит его в int64. Видит surname и просто игнорирует его.

С удалением сложнее. Удалять поля просто так нельзя. Поле должно иметь default значение или быть nullable.

Менять тип например с int на string тоже нельзя. Создаешь рядом поле типа string и какое-то время пишешь сообщения с обоими полями пока все не обновятся. Есть набор правил по которым схема "писателя" может быть проверена на обратную совместимость со схемой "читателя" https://avro.apache.org/docs/1.9.2/spec.html#Schema+Resolution

а можно удалить поле и проставить ему значение по умолчанию?

не, за один шаг нельзя

по идее надо моч помечать поле как depricated, чтобы оно в логи сигнализоровало клиентам. А следующим шагом удалять

это все s2s, тоесть сервер ту сервер. С клиентами, например с мобильными приложениями не работает. Потому что когда там кто обновится никому не известно

Ну с клиентскими приложениями тоже схема более-менее отработанная: по результатам анализа статистики версий клиентов, часть из них в момент X получит сообщение "Качество нашего сервиса является приоритетом для нашей компании бла-бла-бла, поэтому с хренадцатого уебря мы прекращаем поддержку версий старше Х.У.Z"

ну там год или даже два может быть времени

ну или скидывать всех с борта :)

Ну это самом собой! Энтерпрайз и легаси ж.

User {
  Int64 id,
  String name
}

User {
   Int64 id,
  String name,
  String surname
}

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

в нашем случае при публикации схемы в Schema registry ты не можешь нарушить обратную совместимость

т.е. была у тебя схема

User {
  Int64 id,
  String name
}

```
ты попытался опубликовать

User {
  Int64 id
}

а оно тебе и не разрешает