Открытый список вызываемых функций

[gonsalez-ru]

Здравствуйте!
Потребовалось настроить удаленный запуск новой кастомной LUA функции. Пришлось внести правки в 100500+ файлов проекта, но задачку решил и в итоге потерял возможность использовать обновления из репозитория.
Было бы здорово, если бы сервис использовал специальный справочник с описанием допустимых функций и параметров.
Есть ли какие-нибудь архитектурные ограничения, которые не позволят это реализовать?

[Enfernuz]

Не хочу напрягать, но можете на конкретном примере пояснить, как Вы это видите?

По идее, практически все функции, доступные через сервис, маппятся 1-к-1 к соответствующим функциям в QLua. Бывают иногда различия в типах параметров (для переносимости) или объектах возврата.
Само API сервиса, по сути, заключено в .proto-файлах (или JSON-схемах), описывающих сообщения запросов и ответов.

[gojmpz]

Можете пояснить поля null_flags, value_flags для OnAllTrade?
Я полагаю, что value_flags это flags в QLua, но неожиданно натолкнулся на то, что он value_flags бывает пустой. Что такое null_flags?

[Enfernuz]

@gojmpz, это оптимизация для случая, когда в пришедшей от QLua сделке не инициализировано поле flags. Если оставить поле типом int32, то придётся тащить 0 (целое 32-битное число, то есть 4 байта). В случае использования oneof можно заменить сериализацию этого факта 1 байтом (https://stackoverflow.com/a/43696446).

[gonsalez-ru]

Не хочу напрягать, но можете на конкретном примере пояснить, как Вы это видите?

По идее, практически все функции, доступные через сервис, маппятся 1-к-1 к соответствующим функциям в QLua. Бывают иногда различия в типах параметров (для переносимости) или объектах возврата.
Само API сервиса, по сути, заключено в .proto-файлах (или JSON-схемах), описывающих сообщения запросов и ответов.

Я себе представляю это так: добавляем .proto файл с описанием новой функции (например, в специальный пакет custom, по аналогии с пакетом OS), а Lua модули динамически его подхватывают и генерят объекты на основе информации из описания.

P.S. Не судите строго, на Lua никогда не писал, и его возможностей не знаю, поэтому может быть чего-то не догоняю. Ж-)

P.P.S. Я правильно понимаю, что .proto описания и json схемы это альтернативные варианты описания API и сервис может работать с чем-то одним из них?

[Enfernuz]

@gonsalez-ru,

а Lua модули динамически его подхватывают и генерят объекты на основе информации из описания

Проблема в том, что библиотека lua-ptorobuf автоматически генерит только Lua-объекты на основе proto-сообщений. Всю остальную обработку -- то есть, как сервис принимает и обрабатывает такие сообщения (и посылает соответствующие ответные сообщения) -- нужно делать вручную в соответствующих serde-исходниках (для protobuf -- protobuf_request_response_serde.lua). В сущности, большинства такого боилерплейта можно было бы избежать путём использования gRPC, но я не знаю, есть ли сейчас для Lua нормальный генератор grpc-стабов. Когда я начинал разрабатывать проект, такой библиотеки не было.

Я правильно понимаю, что .proto описания и json схемы это альтернативные варианты описания API и сервис может работать с чем-то одним из них?

Это форматы сообщений (запросов и ответов), с которыми работает сервис при выборе соответствующего механизма сериализации и десериализации сообщений. Представленное API одинаково в обоих случаях (ведь цель сервиса -- предоставить доступ к QLua извне). Отличие лишь в том, как сообщения кодируются и декодируются при передаче их от сервиса к клиенту. Protocol Buffers более эффективен с точки зрения размера передаваемых сообщений, но более замороченный в использовании, в то время как JSON более человекочитаем и прост в использовании, но сообщения в этом формате имеют бОльший размер (думаю, даже с учётом использования какого-нибудь алгоритма компрессии типа gzip).