Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

1.0 ready! #195

Closed
buybackoff opened this issue May 14, 2019 · 8 comments

Comments

Projects
None yet
3 participants
@buybackoff
Copy link
Member

commented May 14, 2019

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

  • #100 в базовом виде сделано давно
  • #13 и #7 не касаются цели "повторить QLUA API", для #13 @Pr0phet1c недавно добавил сохранение id ордеров, остальное за пределами цели проекта. #7 - это главная боль Квика, обсуждалось много раз, например последнее в #188. Тоже за пределами проекта, мы работаем с API QLUA как с данностью. Может когда-то кто-то придумает универсальное решение, но это не цель для 1.0. Поэтому ставим крестик тут.
  • #94 - это главное, за чем нужно было следить.

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

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

@buybackoff

This comment has been minimized.

@buybackoff

This comment has been minimized.

Copy link
Member Author

commented May 14, 2019

Другой вопрос - что нужно видеть в версии 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

This comment has been minimized.

Copy link
Member Author

commented May 14, 2019

Вот тут кажется открытый вопрос: #58

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

@buybackoff

This comment has been minimized.

Copy link
Member Author

commented May 14, 2019

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

@Enfernuz

This comment has been minimized.

Copy link

commented May 15, 2019

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

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

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

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

@Pr0phet1c

This comment has been minimized.

Copy link
Collaborator

commented May 15, 2019

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

@buybackoff

This comment has been minimized.

Copy link
Member Author

commented May 16, 2019

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

@buybackoff

This comment has been minimized.

Copy link
Member Author

commented May 16, 2019

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

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

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

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

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

@buybackoff buybackoff closed this May 16, 2019

@buybackoff buybackoff changed the title 1.0 ready? 1.0 ready! May 16, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.