|
Top-level
 > Пока что выглядит так, будто нет подводных камней вообще. @nonsense ну определись уж! Это очень даже подводный камень. К таким придумкам крупных компаний я бы относился с большой осторожностью, т. к. проблемы и нужды крупных компаний сильно отличаются от оных у отдельных разработчиков, небольших команд и опенсорса. Что тебе нужно от формата-то? 4 comments
 @dside @nonsense Имхо если нужны хитрые типы, то тогда уж имеет смысл посмотреть на форматы с описанием типов - capnproto, flatbuffers, protobuffers, ибо завтра может понадобиться не только время, но и, например, литры. А так, чем Int64 не время? И если простых типов хватает, то есть msgpack, простой как пробка и проверенный временем, и с реализованной поддержкой много где. @nonsense Почитал немного про Ion, в отличии от msgpack можно обращаться к полям без декодирования всего сообщения, и это очень значимая фича. Когда я выбирал для своего проекта сериализацию я примерно составил данные которые, как я полагаю, у меня будут и написал серию бенчмарков с разными кодеками. В итоге поменял решение в следующей версии приложения. Бери что удобно, если что потом можно всегда перекодировать, и скорее всего, рано или поздно, придётся. |
Gregory's Server
@dside как минимум, чтобы был встроенный тип для времени