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

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

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

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

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

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

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

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

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

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

делаем /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-символьным именем, то и человеческим глазом спутать можно.

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

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

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

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

> (есть ли у нас клиенты, которые вобше несколько аргументов ей отдают?)
webfetch.php, Qt-клиент + все бывшие клиенты Ромы, включая iipython 0.3 и 51talk.

> Надо дифрекса звать.
Отправил ему только что Email, чтобы появился в этой эхе.

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

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

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

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

Новые коммиты в сабже. Изменения:

* Добавлено полностью рабочее расширение /x/file (со всеми деталями, что обсуждали в ii.14)
* Удалён /x/t, вместо него теперь /x/c (ещё читаемость кода улучшил в той функции)

А что ты думаешь насчёт вот этого сообщения? ii://Vt3hbxrZTExHwhGHOQFn

> А давайте сделаем группу на гитхабе с реализацией эталонной ноды. А то сейчас пхп, питон, перл и еще что-то есть.
> Там можно будет фичреквесты заводить. Т.е., что есть в эталонной ноде автоматически попадает в стандарт.

Для начала нам надо определить, какая нода из тех +-9000 является эталонной =)
Но идея хорошая.

Насчёт новой фичесхемы - будет, но только после того, как мы разберёмся с вон той проблемой, что недавно обсуждали.

Про asciidoc: если просто скопировать содержимое документации, которое у нас уже есть, то без проблем. Если изменять, то пока не знаю, как будет лучше.

> Ящитаю, что без префиксов жизнь плоха. Их не обязательно делать цифровыми, но одна точка в названии эхи быть должна.
Можно и без постфиксов жить, если реализовать нужные стандарты на ноде. Идея с одной точкой вполне жизнеспособна, так как не будет ломать совместимость.

> И длину ID не надо менять. Есть 20 символов и пускай будет 20 символов. Если надо гейтить другую сеть, то решать это надо на стороне ноды, а не стандарта. Т.е. плагинами там или еще как-то.
Лично мне тоже хочется оставить ровно 20. Хотя проверок на длину я даже на ноде не реализовывал. Нода смотрит только алфавит base64 в msgid.

Кстати, интересный факт. Просмотрщик эх, который я набросал летом на ассемблере, рассчитывает, что длина msgid ровно 20 символов. Он делает посимвольный проход по файлу эхи для чтения конкретного айдишника и не будет работать, если хотя бы один msgid имеет не ту длину.

> ЗЫ: имя notii никем не занято?
Погуглил и пояндексил. Никем не занято, за исключением чьих-то никнеймов и какого-то корейского сайта.

Закинул на ноду вот такой скрипт http://ii-net.tk//ii/ii2rss.php

Вечером приду домой и, может быть, сделаю коммит.

> На больших файлах пока не проверял, но на небольших вполне работает. Конечно, это явное переусложнение с одной стороны, а с другой некоторая логическая отвязка от транспортной части.

Если мы собираемся пересылать бандлы с бинарями в твиттере или во вконтактике, то идея однозначно хороша.

> Конечно, это может показаться странным, но кто знает куда придут технологии, а ii иметь хочется независимо от них.
Тогда, если что, буду отдавать файлы в base64. Всё равно скачивать их можно только с помощью authstr, так что спамеры не пройдут.

AL>Вот я тут о цитировании задумался.
А где пробел? =)

VF> Может, вот так, с пробелом?

> Ещё вот надо что-то делать с сабжем, ИМХО. У нас цитаты совершенно не указывают на то, кто их писал. Что мне нравится в Fido, там принято писать первые буквы имени, потом знак > и рисовать им отступ в один пробел.

Идея хороша, но в стандарт это пропихивать не стоит. Пусть будет всего лишь наше негласное правило. Технических сложностей и так хватает.

> У нас же есть @repto.
Конечно, есть. Но тут в другом суть.

К примеру, Андрей написал какое-то сообщение. Предположим,
"123"

Ты на него ответил. Получилось
> 123
456

Меня "зацепило" твоё сообщение, и я решил ответить тебе. Чтобы для удобства различать цитаты разных авторов, можно сделать так:

AL> 123
> 456
789

> Просто я имел в виду визуальный отступ перед сообщением, чтобы визуально его легче было отделять от текущего сообщения.
Тогда некоторые парсеры не будут выделять цитату как цитату (цветом, к примеру).

> Тогда некоторые парсеры не будут выделять цитату как цитату (цветом, к примеру).
Хотя нет, туплю, они же её и так не будут выделять =)

> Ну тогда отступ на откуп клиентов. Но моё предложение в любом случае вынудит переписывать те парсеры. Как бы это ни было печально.
Насчёт переписывать не согласен. Мы же не будем переписывать парсеры схемы ii:// ссылок, если вдруг перейдём на echo:// и msg:// вместо них. Если точнее выразиться, то _добавить новые_ парсеры.

По идее несложно. Регулярка наподобие ^\s{1}[A-Za-zА-Яа-я]{2}>
Старый способ стоит оставить как более привычный.

Регулярку поправил, в base64 /x/file сделал.
Вечером всё протестирую и закоммичу. Даёшь обновы в ii!

Кстати, я планирую одну интересную фичу в Qt клиенте.

> Кстати, я планирую одну интересную фичу в Qt клиенте.
Это будет визуальный редактор для сообщений.
В общем, чтобы виндузятникам не устанавливать vim и всё такое.

Сделал коммит и обновил резервную ноду http://alicorn.tk/ii/ на ветку features. Теперь там можно (наверное) создавать эхи без цифровых постфиксов, использовать новую схему /u/e и делать ещё что-то, что мы обсуждали.

Насчёт /x/file и base64.
Ради интереса пропихнул в список файл размером 188 мб. Поскольку чтение файла и его расшифровка происходит "в лоб", PHP крашится от недостатка ОЗУ.

Файл размером ~4 мб читается без напряга.

Подтверждаю, что оно работает =)

http://alicorn.tk/ii/?echo=ii.test

> Ух ё! Нахер там base64???
На случай передачи по ненадёжным каналам данных =)
Хотя, конечно, по быстродействию это не лучшим образом выглядит.

> Ради интереса посмотри сколько он будет весить в base64 :D
На 33% больше, как и полагается в base64.

> Что ты имеешь в виду? Как base64 поможет?
Посмотри, что Андрей написал выше в эхе.

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

Кстати, в цезии поддержка уже появилась? Я вон в ii://mlp.15 даже маленький скрипт на третьем питоне кидал, чтобы файлы скачивать.
// толку от него всё равно мало, 500-мегабайтные видео не передать из-за base64 ;)

Только что поменял на вариант без base64 у себя на локалхосте и немного подправил скрипт. Теперь видео на ~950мб скачивается без проблем.

Что, даже здесь особо никто не сидит? Чем быстрее проработаем схемы, тем быстрее на них перейдём.
Обратный переход с base64 на бинари (по скорости лучше) до сих пор висит незакоммиченный, надо что-то делать со стандартами, в конце концов.

Тогда...

Коммит.

// кстати, ещё с веб-интерфейсом поработал немного

> Вот я тоже думаю ... Но без переездов бы она сильно упростила жизнь.

unixtime смущает. Это что получается: сервер должен распарсить все N тысяч сообщений на время?

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

> Какие будут предложения? Нужен ли вобще такой метод?

Третий пункт попахивает костылями. Во-первых, хорошо было бы указывать начальный msgid для всех запрошенных эх, т.е. в текущем варианте от него мало пользы. Во-вторых, /u/e и так смещения еле-еле в себя вобрал.

В общем, я за ещё одну схему для списка по msgid.

> Кстати, как ты предполагаешь забирать свежую почту в новом стандарте? Например, клиент всегда забирает последние 50 сообщений, но новых сообщений в эхе 75. Или клиентскую часть ты пока не реализовывал?

Клиентскую часть пока не реализовывал, но скоро собираюсь. Насчёт алгоритма забора почты уже рассказывал: если все 50 сообщений из первого списка новые, то идёт забор -100:50 и так далее аналогично. А сабжевую возможность планирую сделать опциональной (галочка в настройках).

> Только если нода хранит сообщения в файликах, а не в базе.
Да, ведь мы должны гарантировать полноценную работу ноды лишь на файлах. Это ключевая особенность ii. БД - опциональная зависимость.

AL>Буду рад, если найдутся желающие потыкать это поделие палочкой =)
Попробовал написать несколько сообщений в тестовую эху. Обнаружился баг: при обычном запросе /u/e/эха сообщений на 1 меньше, чем в индексе. Отсекается последнее почему-то.

Добавил новую регулярку для цитирования и наконец-то закоммитил ii2rss.php, который за это время вполне удачно себя проявил в деле.

Закоммитил подсветку комментариев в сабж. И заодно в свой Qt-клиент.

В сабже пополнение: скрипт для скачивания через /x/t
Ничего необычного, все маленькие полезные скрипты для работы с ii должны туда рано или поздно попасть.

AL> Очевидно, что на разных нодах может быть разный порядок сообщений в эхах или даже разное содержимое. В связи с чем, я пока придумал только держать отдельную базу сообщений для каждой из нод.
В Qt-клиенте для всех нод одна и та же база. Алгоритм работы примерно таков:
1. Фетчим одну и ту же эху с нескольких нод в одно и то же место
2. Если отправляем туда сообщение, то оно уходит на первую ноду из списка

Каждый из вариантов имеет свои плюсы. Я не стал городить раздельные базы, потому что юзер-НЕфрендли. А произвольную отправку не стал делать, потому что лень =)

vit01>> 2. Если отправляем туда сообщение, то оно уходит на первую ноду из списка

AL>У меня отправляется только то, что было написано для текущей выбранной ноды. И только поинтом с этой ноды. Мне кажется, что так в итоге может быть удобней именно конечному пользователю, так как он не так сильно зависит от сисопов и ему не надо просить прокинуть эху.

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

vit01>> Я не стал городить раздельные базы, потому что юзер-НЕфрендли.

AL> Пока у меня одна база, так как нет смысла, но когда у нас будет возможность получить разный набор сообщений с разных нод, это может стать проблемой.

И где здесь проблема? Предположим, есть эха news.15. На станции 1 туда, к примеру, постят новости с Лора, а на станции 2 - с опеннета. Юзер фетчит их в одну базу. В итоге получает _одну_ ленту с новостями обоих сайтов. Так даже читать приятнее.

> И если мы забираем не всю эху целиком, то возникают потери.
А, теперь понял, в чём здесь суть. Нет, потерь не будет. Я хотел это реализовать с помощью дополнительной кнопки "закачать эху полностью", которую сначала жмёшь в первый раз, а затем уже трафик экономишь.

Ну а так они и без одноимённых эх могут теряться, тут разницы нет большой.

> И если создать разные базы для разных нод, то потерь не будет.

Требую наглядного примера (запрос => результат => файл в общей базе)

Неплохая идея. Это можно во все ноды, где есть /x/, встроить.

Осознал сейчас необходимость того, чтобы в сабже была такая же система конфигурации, как в сишном клиенте и Qt.

Т.е. есть default.config.cfg, и при первом запуске он копируется.

Сделал и закоммитил.

Теперь надо с /x/features и запросом с определённых msgid разобраться.

Надо придумать только, как это реализовать.

Можно сделать что-то вроде такого:

GET /x/features

e/
m/
u/e/
u/m/
u/point
u/push
list.txt
blacklist.txt
x/c/
x/file

Только вот как показать здесь расширенную версию /u/e, не очень ясно. Может быть, /u/e/lim ?

AL> Надо показывать то, чего может не быть: пуш, списки, файлы, каунтеры. Заодно, если показать u/e/, то этим можно обозначить и расширенную версию. Я так это представляю

Действительно. Так и сделаю, когда домой приду.

Запушил. Реализовано всё обычной константой, т.е. просто строку выдаёт.

Оказывается, рабочая реализация "сообщений с определённого msgid" на моей ноде уже имеется. Это /x/e, который был реализован про запас.

Образец

POST /x/e
параметр data равен:

pipe.2032:msgid
ii.14:msgid
ещёэха:msgid

Результат:

pipe.2032
msgid
msgid
msgid
ii.14
msgid
ещёэха
msgid

Если указанного msgid в базе нет, выдаёт всю эху. Если msgid последний в списке, то в результате пустота (нет даже названия эхи).

Когда уже можно будет полностью перейти на новые версии своих нод? Может, реализуем поскорее уже то, что намеревались?

// это сообщение не имеет ничего общего с тем срачем, что устроил Рома; хотел написать его ещё вчера

AL> Я пока никак не могу вебинтерфейс доделать у себя. В принципе, можно обновить php-ноды и пока так оставить.

Планирую слияние features => master и переезд своих основных нод на завтрашний вечер.

И да, насчёт веб-интерфейса. Можешь взять тот, который был у твоего common-lisp клиента. Он очень милый и лично мне понравился. Просто мысли вслух.

Ветки features и master слиты. Миграция ii-net.tk на новую версию ноды завершена.

Перед обновлением настоятельно рекомендуется перечитать файлы config.default.php и README.md.

alicorn.tk также только что сделал сабж.

А вот со станцией mlpfim.ml и некоторыми остальными придётся повозиться, т.к. туда нанесено куча патчей.

Мне бы, наверное, хотелось снова рассказать, какие новые фичи появились в ноде за всё это время. Где это лучше сделать, здесь или в ii.14?