protobuf для fpc

[Дож]

Никто не знает есть ли protobuf для fpc? Я видел protobuf-delphi, который лишь обеспечивает сериализацию примитивных типов в формате протобуфа, по сути это не спасает от ручной работы, а, наоборот, заставляет делать много ручной работы. И это не то, что хочется. А хочется полноценный кодогенератор, причём применительно к fpc можно задействовать свойства вместо геттеров/сеттеров.

Если такого ещё нет, то предлагаю обсудить написание собственного. Нужно ли это кому-то? Как это можно было бы сделать (написать с нуля, взять за основу protoc, и т.д.)?

Добавлено спустя 3 часа 50 минут 45 секунд:
Да, видимо, стандартный путь — это написать дополнительный генератор для protoc (который написан с учётом такой возможности).

[stanilar]

Это что? Реализация протокола обмена между сервисами гугла и прикладухами?

[Дож]

http://ru.wikipedia.org/wiki/Protobuf

[stanilar]

Судя по википедии, из активных пользователей - только твитер.

[Дож]

Судя по википедии, из активных пользователей - только твитер.

Есть вполне себе типовая задача: создание протокола взаимодействия между программами. Задачу можно решить несколькими типовыми способами (в голову приходят xml, yaml, json, bson, но вообще их несметное множество).

Я предпочитаю писать свои собственные бинарные форматы, т.к. не люблю текстовые протоколы и избыточность. Но у меня возникает проблема, что тогда приходится писать много кода для создания и чтения пакета, особенно если отправляющая и принимающая стороны пишутся отдельно. Было бы удобно написать описание бинарного протокола в неком едином месте.

С этой задачей справляется protobuf: он предоставляет язык, на котором пишутся описания пакетов, и к этому языку кодогенератор, который генерирует код на нужном уже в разработке языке, умеющий читать и писать пакеты. Делает это весьма удобно. Сам протокол тоже неплохо продуман, вплоть до того, что можно расширять сообщения новыми полями и это не поломает работу старого кода, обрабатывающего пакеты в старом формате, — что весьма редко обеспечивается при самописных протоколах.

Плюсы и минусы protobuf'а — это отдельный холивар. Мне же интересно есть ли на форуме заинтересованные лица в портировании protoc для поддержки fpc, т.к. у меня много вопросов на обсуждение (даже банальных, типа: как именовать переменные: в принятом для protoc cpp стиле с подчёркиваниями или принятом в паскале CamelCase? .pas или .pp? Как представлять массивы? И т.д.).

Кто в мире глобально использует protobuf неинтересно.

[stanilar]

у меня много вопросов на обсуждение

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

Добавлено спустя 1 минуту 31 секунду:

Я предпочитаю писать свои собственные бинарные форматы, т.к. не люблю текстовые протоколы и избыточность.

А вот зря. При взаимодействии по сети текстовые протоколы предпочтительнее. Да и при меж языковом взаимодействии тоже.

[Дож]

Ок, давайте начнём обсуждение с мелочи.

Плагины к protoc для поддержки новых языков делаются следующим образом: создаётся бинарник вида protoc-gen-$(name), который дальше вызывается когда мы пишем что-то вроде

Код: Выделить всё

protoc -I. --$(name)_out=. something.proto


В сам protoc встроено изначально три языка (--cpp_out, java_out, --python_out). Вопрос: что в качестве $(name) должно быть для паскаля? Разумных вариантов, мне кажется, три: fpc, pas, pascal. Плюсы за различные варианты:
+fpc сразу видно, что плагин заточен под fpc и любителям других вариантов паскаля нужно смириться с этим
+pascal консистентно с точки зрения имеющихся названий (python написан полностью, а не сокращён до py)
+pas коротко, меньше набирать, аккуратно смотрится в консоли
Мне больше всего нравится --pas_out. Ещё мнения?

Теперь к расширениям. Если мы напишем

Код: Выделить всё

protoc -I. --cpp_out=. person.proto


то из person.proto будут сгенерированы два файла: person.pb.h и pesron.pb.cc (pb, видимо, добавлено для избежания коллизий имён). Для fpc нам не нужно генерировать два файла, достаточно всего одного, вопрос: какое расширение должно быть у этого файла? Вижу два варианта: pp и pas.
-pp имя файла вида person.pb.pp смотрится хуже, чем person.pb.pas
-pas складывается традиция в fpc именовать юниты с расширением .pp (?)
+pas --pas_out и .pas гармонично дополнят друг друга.
Я за pas. Ещё мнения?

[stanilar]

Если ориентироваться на поддержку delphi, то надо использовать расширения pas, если разработка будет заточена только под fpc, то использовать pp для избежания путаницы. Думаю надо сразу ориентироваться на поддержу delphi разработчиков, это добавит проекту ценности.

Дож, раз ты взялся за это, может сделаешь страничку в wiki о том, как работать с бинарниками google. Все равно ведь потом такая страничка должна быть уже для pascal, вот и возьмем ее за основу. Можно кратенько, а то мне не включиться в тему.

Добавлено спустя 12 минут 11 секунд:
Кстати, предлагаю создать проект на гуглкоде, чтоб и wiki и issuetracking был в одном месте (форума тока не хватает).

[Дож]

Гуглкод будет, отчасти для его создания мне нужно название

Дож, раз ты взялся за это, может сделаешь страничку в wiki о том, как работать с бинарниками google. Все равно ведь потом такая страничка должна быть уже для pascal, вот и возьмем ее за основу. Можно кратенько, а то мне не включиться в тему.

Не понял, чем не подходит официальная документация? Типа этой https://developers.google.com/protocol- ... pptutorial

Для паскаля по ходу дела буду писать.

[stanilar]

чем не подходит официальная документация?

Подходит. Но нужно исключить разночтения и т.п.

Думаю что название за тобой (хотя вариантов немного).

[Vapaamies]

Тема двоичных протоколов настолько меня заинтересовала, что ознакомился с докой Google и проникся идеей. Неплохой стандарт, проработанный. Кстати, для хранения отрицательных чисел в нем используется нега-позиционная система счисления, -- у нее даже термин официальный есть.

+pascal консистентно с точки зрения имеющихся названий (python написан полностью, а не сокращён до py)

Однозначно голосую за pascal_out, ибо pas_out -- самодельщина какая-то. Завидев pas_out, я бы задумался о разработке собственной реализации.

Если ориентироваться на поддержку delphi, то надо использовать расширения pas, если разработка будет заточена только под fpc, то использовать pp для избежания путаницы. Думаю надо сразу ориентироваться на поддержу delphi разработчиков, это добавит проекту ценности.

Полностью поддерживаю, это прекрасно согласуется с концепцией pascal_out. Расширение файла -- вообще не вопрос, его можно опцией задавать:

Код: Выделить всё

option pascal_unit_name_extension = ".pas" // или ".pp"


Саму опцию, ясное дело, должен обрабатывать паскалевский кодировщик.

[Дож]

Расширение файла -- вообще не вопрос, его можно опцией задавать:

Код: Выделить всё

option pascal_unit_name_extension = ".pas" // или ".pp"


Считаю это в корне неправильным подходом. Файлы протобуфа — это некая абстракция для описания сообщений. Один файл протобуфа может использоваться разными людьми, разными языками. Разработчик на паскале, возможно, не сам написал .proto-файл, а взял откуда-то и не может или не хочет его менять. Наконец, один .proto-файл может гипотетически быть использован и для создания .pas-файла, и для создания .pp-файла.

Поэтому если делать настройку, то в качестве параметра командной строки, а не опции самого .proto-файла.

[Vapaamies]

Поэтому если делать настройку, то в качестве параметра командной строки, а не опции самого .proto-файла.

А как это сделать? Как понял, интерфейс обработчиков выходных форматов protoc не позволяет передавать им дополнительные параметры. Можно, конечно, сделать bat- или sh-файлы, обертывающие вызов обработчика с нужным параметром, но вместо этого Google предлагает концепцию единого входного языка, которую я считаю верной.

Предположим, есть некий файл 3rdParty.proto, скачанный с Интернета. Параметр выбора целевого синтаксиса и/или расширения, будучи реализован внутри кодировщика, может задаваться путем расширяющего импорта. Программист может создать файл my-fpc.proto:

Код: Выделить всё

option pascal_syntax = objfpc
import "3rdParty.proto"


Или my-delphi.proto:

Код: Выделить всё

option pascal_syntax = delphi
import "3rdParty.proto"


Для Паскаля возможны следующие параметры:

• pascal_syntax -- перечисление (objfpc, delphi), влияет на автоматически выбираемое расширение имени -- ".pp" или ".pas".
• pascal_unit_file_name_extension -- можно задать ".pp" или ".pas", перекрыв умолчание.
• pascal_namespace -- именовать выходной модуль как "namespace.%UnitName%", может быть полезно для режима Delphi.
• pascal_objects -- (чисто теоретически) выбор между генерацией классов (class) и объектов (objects), если поставляемая библиотека будет иметь режим объектов.

[Дож]

А как это сделать?

Это уже немного другой вопрос :) Главное — хотим или нет? Лично я считаю, что расширение должно настраиваться командной строкой, а не .proto-файлом, т.к. даже хаки с импортом не очень удобны.

Передача параметров в плагины поддерживается в параметре --foo_out=parameter:outdir, например:

Код: Выделить всё

protoc -I. --pascal_out="objfpc,ext=.pp,use_namespaces,objects:myproject/output/files" person.proto


Бонус (вероятно, бесполезный, но приятный) такого подхода — одним вызовом можно будет сгенерировать несколько выходных паскалевских файлов с разными аргументами.

pascal_objects -- (чисто теоретически) выбор между генерацией классов (class) и объектов (objects), если поставляемая библиотека будет иметь режим объектов.

Если поставляемая библиотека будет иметь режим классов! :) Ибо считаю реализацию в виде объектов более правильной в плане производительности и удобства. Объекты для меня более приоритетны, чем классы. Предлагаю сразу тогда обсудить этот момент.
-class лишняя нагрузка на динамическую память, особенно критично при обработке большого числа сообщений из сети
-class лишнее RTTI (в то время, как от протобуфа достанется своя)
-object в некоторых местах будет индивидуальный подход к передаче параметру — через var переменную или указатель

Придумать совместимый с обоими вариантами дизайн клиентского кода не так-то просто, так как у классов и объектов по-разному вызываются конструкторы и передача параметрами тоже может быть разной (с или без @, в частности).

[stanilar]

Насколько понимаю файл proto - спецификация сообщений обмена. Не думаю что в нем можно (да и нужно) определять расширения, файлы и т.п.. По идее пользователь должен взять любой файл proto, и не изменяя его получить рабочий файл для проекта.

Что касается выбора между class и object, то это преждевременный вопрос. Для начала надо понять какими сущностями оперирует гугловский компилятор, и работать с тем, что ему ближе.

Неоправданно опущена возможность определить вместо class/object тип record, а ведь его использование может оказаться более выгодным для бинарного формата, и более совместимым между языками программирования, т.к. object выпилен из последних delphi компиляторов.

Кстати сказать, record из последних дельфи ближе к object из FreePascal чем к record из FreePascal, возможно должна быть возможность комбинировать object/class/record в зависимости от целевого компилятора.