search

finsight / QUIKSharp

QUIK# (QUIK Sharp) is the QUIK Lua interface ported to .NET.
Other
232 stars 135 forks source link

1.0 ready! #195

Closed buybackoff closed 5 years ago

buybackoff commented 5 years ago

У нас была milestone https://github.com/finsight/QUIKSharp/milestones/1.0 для 1.0.

В итоге вопрос - осталось ли что-то, что мешает выкатить версию 1.0 и обновить NuGet так, чтобы людям не приходилось строить проект самим. Текущий NuGet пакет c ноября 2017 и вряд ли годен, много фиксов было с тех пор.

@Pr0phet1c @nubick @DevelopMan @stanislav-111 @SkyN @IFetisov и все, кто следит за проектом - можно выкатывать 1.0 на NuGet и объявить библиотеку стабильной? И если нет - то что еще осталось?

buybackoff commented 5 years ago

@alexmgerasimov @sm00vik @Nikolaev-Nikolay @Prival1 @mkurtm @spvik

buybackoff commented 5 years ago

Другой вопрос - что нужно видеть в версии 2.0?

Моей ошибкой было сделать самопальный протокол на коленке (история со стороками и разделителями |). Это было сделано в первые дни работы и так и осталось, работает тупо, но надежно. Но нужно было делать JSON-RPC, тогда история с работой из разных языков была бы гораздо проще: каждой функции/колбэку QLUA соответствовала бы четкая структура данных JSON, и C# клиет был бы лишь одной из возможных имплементаций.

@Enfernuz делает коннектор на основе ZeroMQ и ProtoBuf, и добавляет JSON - но тоже не в стандарте JSON-RPC, а в самопальном. Это все одно и то же - название метода + параметры, но хорошо соблюдать стандард, тогда гораздо легче интегрироваться с другими языками. Готовые библиотеки JSON-RPC позволяли бы вызывать методы напрямую, скрывая работу по (де)сериализации от пользователей. Для Python/JavaScript/TypeScript это было бы особенно актуально.

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

Я бы хотел предложить @Enfernuz стандартизировать прослойку Lua, чтобы она использовала JSON-RPC, в идеале по одному порту (а не по двум как тут сейчас или двум каналам ZeroMQ - REQ-RESP + PUB-SUB). Но транспорт должен быть интерфейсом и могут быть разные реализации. Payload в виде JSON-RPC совершенно не зависит от транспорта, так что можно разделить транспорт и формат:

   QLUA API             --------
          |                               |
   JSON-RPC           (Lua inside Quik)
          |                               |
   Transport              -------
          |                               |
    JSON-RPC                (Clients)
          |                               |
     Connector code           |
         ...                             ...

Форматирование выше едет, но идея в том, что payload сообщения стандартный на уровне транспорта и соотвествует протоколу JSON-RPC. Эта библиотека (Q#) никогда не будет использовать ничего для транспорта, кроме сырых TCP сокетов и строковых payloads, потому что это бессмысленно, но прослойку выше транспорта нужно стандартизировать.

P.S. А если у кого-то есть выход на ARQA или кто-то из ARQA это читает - скажите им, что они очень нехорошие люди, раз еще не сделали сами JSON-RPC интерфейс. У них всё для этого есть, и я не могу понять, почему они этого не делают - это решение привязывает пользователей к Квику, а отсутствие такого решения в конечном счете быстрее толкает пользователей в сторону Плазы и т.п.

buybackoff commented 5 years ago

Вот тут кажется открытый вопрос: https://github.com/finsight/QUIKSharp/issues/58

@sergshabal это еще акуально?

buybackoff commented 5 years ago

Запостил на Смарт-Лабе: https://smart-lab.ru/blog/538825.php

Enfernuz commented 5 years ago

@buybackoff, здравствуйте.

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

Что касается сокетов: возиться с ними изначально не было желания, поэтому и был выбран ZeroMQ в качестве прослойки более высокого уровня (хотя и с ней тоже пришлось повозиться, конечно).

Я, если честно, в последнее время смотрю в сторону grpc -- на Lua, кажется, что-то толковое делают уже (https://github.com/jinq0123/grpc-lua).

Pr0phet1c commented 5 years ago

С моей стороны противоречий вроде бы нет. Думаю, можно релизить 1.0. В любом случае, я продолжаю работать с этой библиотекой и буду стараться ее обновлять по мере необходимости. На счет 2.0 - это для меня уже сложно. Я могу лишь какие-то прикладные задачи решать.

buybackoff commented 5 years ago

Пакет RC1, скачанный c NuGet, запускается из dotnetcore3.0. Не долго думая в ближайшие минуты опубликую 1.0 и закрою этот последний issue.

buybackoff commented 5 years ago

Поздравляю всех с 1.0!

Текущий срез 1.0 стабилен для абсолютного большинства задач при работе с Квиком.

Фиксить баги и добавлять что-то, связанное с QLUA API (#94) будем как раньше в обычном порядке и сразу пушить на NuGet с весиями 1.0.X для багов или 1.Y.0 для новых фич.

Идеи для 2.0 - на очень далекое будущее, чтобы обсудить. В ближайшее время я не смогу заниматься этим проектом глубже, чем базовая поддержка/обновления.

Могу дать @Pr0phet1c доступ к NuGet (если еще не делал этого). Сейчас упаковка/публикация через пару кликов (скрипты), мне в принципе и самому будет не сложно, так что это по желанию.