Tarantool клиент на чистом php

[Eugene Leonovich]

Добрый день,

Я создал клиент к тарантулу на чистом php. Это пока альфа и api еще будет меняться, но клиент на данный момент вполне работоспособный — проходит все тесты официального pecl клиента (tarantool-php), + множество своих тестов, которые еще не проходит официальный клиент (багрепорты отправлены). В планан — завести все это дело на hhvm (не хватает только потокового msgpack декодера для hhvm) и добавить документацию ;). Так же у меня есть работающий прототип асинхронной версии клиета на базе reactphp, который на моей машине чуть быстрее (в пределах погрешности) либо сопоставим по скорости с питоновским gtarantool’ом (замерял вставку статыщ элеметнов).

Я собираюсь выложить эту и другие библиотеки на packagist.org. Я могу опубликовать их под своим неймспейсом, например, “tarantoolphp/client", либо под “tarantool/client”. Для последнего варианта мне нужны права мейнтейнера неймспейса “tarantool”. Cобственно вопрос, заинтересованы ли разработчики в опубликации этих пакетов под официальным неймспейсом?

П.С. На данный момент под tarantool'ом выложено 2 пакета (tarantool/tarantool и tarantool/stubs). Насколько я знаю, пекловские пакеты (pecl extensions) не поддерживаются composer'ом, для этого пилится другой менеджер, который будет скачивать и собирать пакеты из pecl репозитория, то есть, по сути, "tarantool/tarantool” как pecl extension бесполезен для соmposer'a и я бы рекомендовал его удалить, дабы не смущать пользователей.

[Eugine Blikh]

Добрый день, Евгений.

Спасибо большое, я могу разместить ссылку на ваш коннектор на сайте tarantool.org. Поддержка HHVM это приятный бонус. 

Я не осознал как именно даются права мейнтейнера на неймспейс "tarantool" для packagist. Если бы вы объяснили поподробнее, то я бы с радостью вам их дал.

P.S. ошибку осознал, расширение удалю.

С наилучшими пожеланиями, Евгений.

19 июня 2015 г., 11:20 пользователь Eugene Leonovich <gen....@gmail.com> написал:

--
Вы получили это сообщение, поскольку подписаны на группу "tarantool-ru".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес tarantool-ru...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

[Eugene Leonovich]

> я могу разместить ссылку на ваш коннектор на сайте tarantool.org

Было бы здорово ;)

> Я не осознал как именно даются права мейнтейнера на неймспейс "tarantool"

 Я не уверен, но, возможно, если перейти на страницу любого из пакетов  и в правом вернем блоке (рядом c мейнтейнером) нажать [+], то это сработает.

[Roman Tsisyk]

Friday, June 19, 2015 4:39 AM -07:00 from Eugene Leonovich <gen....@gmail.com>:
>

Быть может назвать tarantool-php-pure или что-то около того?

Пользуясь случаем хотел поинтересоваться точно ли нужен отдельный репозиторий tarantool-php-stubs для заглушек или может достаточно в самом taranool-php создать папочку?

--
WBR,
Roman Tsisyk <ro...@tarantool.org>
http://tarantool.org/ - an efficient in-memory data store and a Lua application server

[Eugene Leonovich]

> Быть может назвать tarantool-php-pure или что-то около того?

Мне кажется, что вынести php либы в отдельную организацию все же лучше. Я планировал разделить tarantool-php/client на два репозитория, один будет общим кодом для всех клиентов, например, tarantool-php/common (или tarantool-php/protocol), другой будет содержать только код для синхронного клиента (tarantool-php/client). Позже я добавлю асинхронный tarantool-php/react-client, и php версию pecl клиента -  tarantool-php/polifill. Так же я написал php либу для работы с tarantool/queue, которую тоже я собирался опенсорснуть вскорости.

Получается довольно много php кода для общего репозитория:

tarantool-php/common
tarantool-php/client
tarantool-php/react-client
tarantool-php/polifill
tarantool-php/queue

(pаньше там еще был tarantool-php/stubs, но потом было решено, что имеет смысл положить его рядом с официальным клиентом).

> точно ли нужен отдельный репозиторий tarantool-php-stubs

Лично я считаю, что да. По крайней мере, мне кажется излишним скачивать весь репозиторий ради одного php файла. Причем, каждый раз при обновлении репозитория придется скачивать эти изменения, даже если сам php файл не поменялся. Все похожие проекты, что я видел обычно имеют отделный репозиторий для стабсов.
Но, как вариант, можно создать отдельную ветку в tarantool-php репозитория и указать композеру скачивать стабсы оттуда.

[Konstantin Osipov]

* Roman Tsisyk <ro...@tarantool.org> [15/06/20 02:22]:

>
> Friday, June 19, 2015 4:39 AM -07:00 from Eugene Leonovich
> <gen....@gmail.com>:
> >
>
> Быть может назвать tarantool-php-pure или что-то около того?
>
> Пользуясь случаем хотел поинтересоваться точно ли нужен отдельный репозиторий tarantool-php-stubs для заглушек или может достаточно в самом taranool-php создать папочку?
>

https://github.com/tarantool/tarantool-php/pull/40


--
http://tarantool.org - a NoSQL database in a Lua script

[Konstantin Osipov]

* Eugene Leonovich <gen....@gmail.com> [15/06/20 02:22]:

> > Быть может назвать tarantool-php-pure или что-то около того?
>
> Мне кажется, что вынести php либы в отдельную организацию все же лучше. Я

> планировал разделить *tarantool-php/client *на два репозитория, один будет
> общим кодом для всех клиентов, например, *tarantool-php/common* (или
> *tarantool-php/protocol*), другой будет содержать только код для
> синхронного клиента (*tarantool-php/client*). Позже я добавлю асинхронный
> *tarantool-php/react-client*, и php версию pecl клиента -
> *tarantool-php/polifill*. Так же я написал php либу для работы с
> *tarantool/queue*, которую тоже я собирался опенсорснуть вскорости.

>
> Получается довольно много php кода для общего репозитория:
>

> *tarantool-php/common*
> *tarantool-php/client*
> *tarantool-php/react-client*
> *tarantool-php/polifill*

+1

[Roman Tsisyk]

Friday, June 19, 2015 2:00 PM -07:00 from Eugene Leonovich <gen....@gmail.com>:

>
> > Быть может назвать tarantool-php-pure или что-то около того?

> Получается довольно много php кода для общего репозитория:
>
> tarantool-php/common
> tarantool-php/client
> tarantool-php/react-client
> tarantool-php/polifill
> tarantool-php/queue
>

Возможно, что это всё будет весьма трудно синхронизировать между собой и поддерживать в актуальном состоянии. Слишком мелкая раздробленность получается. Представьте, мы добавляем новое поле в одну из команд протокола. Какие репозитории надо будет менять? protocol, common, client?

Разделение на репы имеет смысл, если каждый подпроект будет жить своей жизнью. Но тогда в общих частях вроде common и protocol надо поддерживать стабильное внутреннее API, дабы не ломать client и остальное. Ввиду того, что внутренние кишки не особо волнуют конечных пользователей, то получается создание искусственных ограничения на код. Кстати, в таком разделении на репы RPM/DEB также будут собираться отдельно для каждой репы. Поэтому надо быть готовым к тому, что кто-нибудь обновит client, но забудет обновить protocol.

> Лично я считаю, что да. По крайней мере, мне кажется излишним скачивать весь репозиторий ради одного php файла. Причем, каждый раз при обновлении репозитория придется скачивать эти изменения, даже если сам php файл не поменялся.

У нас же не 14.4к, да и git выкачивает ровно то, что поменялось. Насколько я понимаю, содержимое stubs должно соответствовать содержимому драйвера. Если добавляется какая-то функция в драйвер, то надо добавлять эту же функцию в stubs. По сути stubs - это как документация. Каждой конкретной ревизии драйвера соответствует ревизия документации и два данных репозитория не могут жить с раздельным lifecycle. Именно по этой причине мы не выносим сайт и документацию из дерева исходников Tarantool.

Но всё выше сказанное тут больше IMHO. Если так реально будет удобнее, то хорошо.
Главное чтобы в итоге на выходе были пакеты для дистрибутивов и документация по их использованию :)

[Eugene Leonovich]

> Возможно, что это всё будет весьма трудно синхронизировать между собой и поддерживать в актуальном состоянии. Слишком мелкая раздробленность получается. Представьте, мы добавляем новое поле в одну из команд протокола. Какие репозитории надо будет менять?

Придется обновлять каждый клиент и основной репозиторий. Но я надеюсь, что апи не будет часто меняться ) С другой стороны, мы не можем запихнуть всё в один репозиторий. Например, если бы мы решили положить pure php версию tarantool-php клиента (polifill) в "tarantool/tarantool-php" репозиторий (тот же агрумент, что и для стабов - каждой конкретной ревизии драйвера должна соответствовать ревизия полифила, репозитории не могут жить с раздельным lifecycle), то получается, что придется запихнуть весь пхп код в репозиторий, так как по сути полифил -- это просто адаптер, которой внутри будет использовать "tarantool-php/client", а тот в свою очередь -- "tarantool-php/protocol".

> Именно по этой причине мы не выносим сайт и документацию из дерева исходников Tarantool.

Всё же с документацией ситуация немного другая -- чтоб ей воспользоваться, достаточно открыть сайт, то есть скачивать её из репозитория совсем не обязательно. Stub'ы же нужны на локальном компьютере пользователя, и, желательно, чтоб процесс обновления был автоматизирован.

> Кстати, в таком разделении на репы RPM/DEB также будут собираться отдельно для каждой репы. Поэтому надо быть готовым к тому, что кто-нибудь обновит client, но забудет обновить protocol.

Я не сильно знаком с процессом сборки RPM/DEB пакетов, но скорее всего можно просто включить protocol в код клинта при сборке, и поставлять только client, react-client и т.д. Кроме того, можно все клиенты положить в метапакет (как, например, сделал zend фреймворк -- https://github.com/zendframework/zf2/blob/master/composer.json).

Я согласен, что у каждого подхода свои минусы и плюсы. Тут больше вопрос об удобстве для конечных пользователей vs разработчиков. Хранить все в одном репозитории удобно для разработчиков, иметь возможность скачивать только то, что нужно, обновлять либу только когда она реально обновилась (а не только файл асинхронного клиента, хотя им и не пользуются), -- все это удобней для пользователя.

[Eugene Leonovich]

Евгений, есть какие либо новости по поводу packagist.org? Пробовали ли вы добавить меня мейнтейнером?

[Eugine Blikh]

Добрый день, Евгений. Простите за задержку - попробуйте сейчас?

С наилучшими пожеланиями, Евгений.

23 июня 2015 г., 10:39 пользователь Eugene Leonovich <gen....@gmail.com> написал:

[Eugene Leonovich]

Работает. Спасибо )

[Eugene Leonovich]

Еще один момент. Чтобы "tarantool/stubs"  обновлялся автоматически на packagist.org, нужно добавить соответсвующий севрис в настройках репозитория на github:
Settings -> Webhooks & Services -> Add service, затем выбрать Packagist и вставить токен, который взять с этой страницы https://packagist.org/profile/.

[Eugine Blikh]

Поправил, моя ошибка:) Webhook был настроен неправильно.

23 июня 2015 г., 14:18 пользователь Eugene Leonovich <gen....@gmail.com> написал:

Еще один момент. Чтобы "tarantool/stubs"  обновлялся автоматически на packagist.org, нужно добавить соответсвующий севрис в настройках репозитория на github:

С наилучшими пожеланиями, Евгений.

[Alexandre Kalendarev]

народ, если реально нужно запилить клиент тарантул под HHVM, то могу попробовать. Я делал пробники расширений для HHVM, но пока ничего нужного для себя не сделал.

[Eugene Leonovich]

Текущий php клиент работает на hhvm, единственная проблема на данный момент в msgpack декодере, он пока парсит респонс исходя из того, что хедер фиксированный.
Мне нужно переписать эту часть, там ничего сложного нет, просто пока руки не дошли.

Единственное, что можно улучшить, так это запилить нативный стримовый декодер, возможно это ускорит парсинг.
Я создал тикет по этому поводу пару дней назад: https://github.com/reeze/msgpack-hhvm/issues/7

[Alexandre Kalendarev]

хорошо, будет время - подумаем

15 июля 2015 г., 12:01 пользователь Eugene Leonovich <gen....@gmail.com> написал:

--

Вы получили это сообщение, поскольку подписаны на группу "tarantool-ru".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес tarantool-ru...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--

Alexandre

[Eugene Leonovich]

Кстати, теперь клиент работает на HHVM.