Избавляемся от /x/t в пользу /x/count?

Предлагаю также /x/count переименовать в /x/c

Ещё нашёл кое-какую недоработку в нашем алгоритме /u/e/эха/лимит.
Поскольку мы постфиксы делаем необязательными, люди могут называть эхи только числами

Тогда запрос /u/e/20/30 можно истолковать двояко: выбрать эхи 20 и 30, либо выбрать 30 первых сообщений из эхи 20.

Обходное решение - сделать двоеточие обязательным. Тогда запрос для выборки первых 10 сообщений будет выглядеть, как /u/e/echo/0:10
Для последних -10:10

// ветку features возрождаю, после уточнения алгоритма точно обновлю API

Изменения в ветке features php-ноды:
* убрал обязательные постфиксы
* расширил /u/e/ по обновлённой схеме с учётом предыдущего сообщения

Теперь нам надо думать, как отличать эхи от сообщений в бандле (они ж без постфиксов теперь). O_o

>Избавляемся от /x/t в пользу /x/count?
Всё таки это разные схемы. С другой стороны, кто у нас поддерживает /x/t?

>Предлагаю также /x/count переименовать в /x/c
Почему бы и нет. Это лучше соответствует общей стилистике именования.

>Ещё нашёл кое-какую недоработку в нашем алгоритме /u/e/эха/лимит.
>Поскольку мы постфиксы делаем необязательными, люди могут называть эхи только числами
>Тогда запрос /u/e/20/30 можно истолковать двояко: выбрать эхи 20 и 30, либо выбрать 30 первых сообщений из эхи 20.
Положим, я бы не стар разрешать обзывать эхи только числами, но тут надо голосовать - надо такое или нет.

>Обходное решение - сделать двоеточие обязательным. Тогда запрос для выборки первых 10 сообщений будет выглядеть, как /u/e/echo/0:10
>Для последних -10:10
Как вариант, кстати, да.

> Всё таки это разные схемы. С другой стороны, кто у нас поддерживает /x/t?
Только мой Qt-клиент. Мне переименовать /x/t в /x/c - на раз-два. А алгоритм работы менять даже не придётся.

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

> Как вариант, кстати, да.
Так и поступил в ветке features.

И ещё (цитирую самого себя):

> Теперь нам надо думать, как отличать эхи от сообщений в бандле (они ж без постфиксов теперь). O_o

Раньше проверка всегда шла по точке. Есть точка в названии - значит оно является эхой. Настоящая ситуация полностью ломает все фетчеры, и это реальная проблема.

>> Теперь нам надо думать, как отличать эхи от сообщений в бандле (они ж без постфиксов теперь). O_o
>Раньше проверка всегда шла по точке. Есть точка в названии - значит оно является эхой. Настоящая ситуация полностью ломает все фетчеры, и это реальная проблема.
Не вижу большой беды. Разве что ii-ссылки придётся переделать, а остальное нормально и так должно работать. Пока нет времени, но при случае попробую реализовать безточечный вариант. А вот имена эх в виде чисел это как-то излишне и я бы блокировал создание таких эх на ноде. Но тут думать надо, а я на вскидку говорю. Написать тесты, посмотреть какую логику взаимодействия можно реализовать и насколько она останется простой. Плюс надо сохранить совместимость как со стороны клиентов, так и со стороны ноды. В общем, я не готов сейчас писать что-либо адекватное по теме.

Проект iing у меня не заброшен, но пока приостановлен.

> Не вижу большой беды. ... , а остальное нормально и так должно работать. Пока нет времени, но при случае попробую реализовать безточечный вариант.

Ладно, объясню конкретно:

делаем /u/e/test.15/myechoarea/ii.test.15
выводит

test.15
msgid
msgid
msgid
msgid
msgid
myechoarea
msgid
msgid
ii.test.15
msgid
msgid
msgid

Как фетчер поймёт, что myechoarea - это эха, а не сообщение? А если мы назовём эху 20-символьным именем, то и человеческим глазом спутать можно.

Рома предлагал в таком случае ставить в начале имени эхи двоеточие. Но тогда ломается совместимость.

> Плюс надо сохранить совместимость как со стороны клиентов, так и со стороны ноды.
----

> А вот имена эх в виде чисел это как-то излишне и я бы блокировал создание таких эх на ноде. Но тут думать надо, а я на вскидку говорю.

Можно сделать регулярку, которая требует как минимум одну букву в названии эхи. Хотя это не принципиально. Надо бы спросить остальных.

>Ладно, объясню конкретно:

>делаем /u/e/test.15/myechoarea/ii.test.15
>выводит

>====
>test.15
>msgid
>msgid
>msgid
>msgid
>msgid
>myechoarea
>msgid
>msgid
>ii.test.15
>msgid
>msgid
>msgid
>====

>Как фетчер поймёт, что myechoarea - это эха, а не сообщение? А если мы назовём эху 20-символьным именем, то и человеческим глазом спутать можно.

>Рома предлагал в таком случае ставить в начале имени эхи двоеточие. Но тогда ломается совместимость.

Ну тут у нас всего два варианта: либо схема /u/e будет принимать только один аргумент (есть ли у нас клиенты, которые вобше несколько аргументов ей отдают?) или ломаем совместимость с помощью того же двоеточия. Надо дифрекса звать. Я несколько дней думал, но однозначного ответа придумать не смог. С одной стороны двоеточие будет хорошим шагом, но тогда точно не останется совместимости и придётся пилить поддержку нового стандарта в своих клиентах (мне не тяжело, но как на нас посмотрят остальные? =)

>> А вот имена эх в виде чисел это как-то излишне и я бы блокировал создание таких эх на ноде. Но тут думать надо, а я на вскидку говорю.

>Можно сделать регулярку, которая требует как минимум одну букву в названии эхи. Хотя это не принципиально. Надо бы спросить остальных.

Можно много чего сделать. Наверное или Дифрекса надо звать или вобще эху уже делать открытой и написать объявлние в ii.14.

И да, насчёт множественных аргументов в /u/e

У меня в подписках:
на ii-net.tk 18 эх
у Андрея 2 эхи
на irk39.tk 7 эх
и на localhost 1 эха

В текущем варианте для получения полного списка сообщений клиент делает 4 запроса (и опциональный /x/t вдобавок).
Если перейти на единичный аргумент, то их будет 28, то есть в 7 раз больше.

Так что со своей стороны говорю, что вариант превращения /u/e в /e выглядит полным ужасом =)