Для осмысленных выборок из базы ноды клиенту необходимо знать сколько сообщений в эхоконференции имеется. Для этого я реализовал расширение в виде схемы /x/count. Работает это так: запрашиваем у ноды /x/count/ii.14 и получаем количество сообщений в эхе ii.14.

Нововведение уже в репозитории.

Мне кажется, что /x/count не нужен, потому что новый интерфейс с минусами и лимитами, который я предложил, убирает в нём необходимость.
Для начала клиент забирает последние n сообщений, затем если среди них все новые (либо первое из полученных новое, что проще проверить), то он забирает -2n:n, -3n:n и так далее в цикле.

Кстати, /x/t в php-ноде работает точно так же, как /x/count =)

>Мне кажется, что /x/count не нужен, потому что новый интерфейс с минусами и лимитами, который я предложил, убирает в нём необходимость.
>Для начала клиент забирает последние n сообщений, затем если среди них все новые (либо первое из полученных новое, что проще проверить), то он забирает -2n:n, -3n:n и так далее в цикле.
Если, например, я знаю название эхи, но не забираю /list.txt, то для построения хитрого запроса может понадобиться знать число сообщений. К тому же запрос count удобнее и проще парсинга list.txt.

>Кстати, /x/t в php-ноде работает точно так же, как /x/count =)
Блин. Ну переделать count на t не долго.

> для построения хитрого запроса
> хитрого
Ой, не заметил этого слова =) Теперь все претензии снимаются, получать количество в таком случае вполне нормально.

> Блин. Ну переделать count на t не долго.
Я просто поставлю, чтобы они одинаковыми были, если что.

Дело тут в том, что /x/t - это более расширенная схема. В стандарте говорится, что она должна выдавать "версию базы", которая может являться абсолютно любым числом, но увеличивающимся со временем. Я реализовал /x/t на основе количества сообщений. В принципе, /x/t нигде кроме Qt клиента не реализован, так что можно от него избавиться и переименовать в /x/count или /x/c