Обновления в сабже:
1. Исправлен rss-бот, убрано куча тормозов и ненужностей, из-за которых были дубли.
2. Улучшена читаемость кода в некоторых местах
3. Поправлен push (советую обновиться, так как ранняя опечатка делала ноду уязвимой)
4. В читалке количество сообщений учитывает блэклист
5. Адрес ноды вынесен в конфиг

Обновлена документация на irk38.tk, внесено куча мелких исправлений и уточнений, стандартизирован list.txt, push ушёл в расширения, а также был описан его формат. Скачать: http://irk38.tk/ii-doc.tar.gz
Читать: http://irk38.tk/ii-doc

(Надо бы давно обновить её на iinet.sexy)

> done
А главная страница проекта index.html с ещё одним моим емейлом и ссылкой на ii-net.link? =)

А, нет, всё нормально обновилось, извиняюсь

Немного поменял http://irk38.tk/iidownload/ , теперь там написано, наверное, обо всём ii-софте, который вообще есть.

Пусть останется тогда. Когда выпустишь нормальную версию, ссылку поменяю
И да, /blacklist в стандарт не входит, см. im.100

О да, поддержка офлайна!
Уже качаю

Уже и первый баг: сообщения загружаются не циклом, а при нажатии кнопки. По размеру бандла. Буду отправлять.

Чёрт, im.100 и другие длинные эхи так неудобно читать, они с самого начала подгружаются

Но смысл? И так всё надёжно работает, зачем ломать совместимость?

> а в чём смысл хранить совместимость, если в сети существует всего две-три станции, с периодом жизни два раза в сутки :)
Кроме станций есть ещё и много клиентов, которые с этими станциями работают, и некоторое количество служебных скриптов для каждой из них + для клиентов.

> когда можно запросить только последние 500, будет проще синкаться.
Но когда на одной из станций за период синхронизации напишут 600 сообщений при том, что синхронизация идёт по 500, то оставшиеся 100 затеряются. Конечно, эта идея экономит трафика достаточно, но всё-таки лучше определённую надёжность иметь.

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

> карбонок нет нормальных :)
Как я понял, это можно простеньким скриптом реализовать :)

Вот инициативу с убиранием обязательных цифровых постфиксов в эхе я бы поддержал (это удобно, конечно, но такое искусственное ограничение не оправдано), но надо придумать, как различать эхи и сообщения.

> Не понял.
Так, объясню. К примеру, у меня размер бандла 20 сообщений
Я захожу в эху, загружаются 20 сообщений (не все, а только это число)
Жму обновить, загружается ещё 20. Потом ещё, но только если нажать на кнопку. В im.100 больше тысячи сообщений, как мне последние прочитать?

Стих из комментариев (Subrisk):

Чтоб коллапс вдруг не настал,
Применяйте коде-стайл.
Делай совершенный код,
Чтобы понял даже кот.

Комментировать не надо,
Код всё скажет за тебя.
Проектируй до упада,
Композицию любя.

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

=)

Обновил ссылку на http://irk38.tk/iidownload

Хотелось бы посмотреть в точном (техническом) описании всё, о чём ты в этом сообщении сказал. Кое-что показалось интересным, но многое требует уточнения.

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

Ну ладно, придётся мне читать код :)

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

> Офигеть:)
> А у тебя есть терминал на телефоне? Надо бы проверить, как выполняется запрос
Есть, конечно =) Без терминала телефоном почти невозможно пользоваться =)
Расскажи, как проверить

http://irk38.tk/screen1.png
они, как ты видишь, самые "несвежие"

Я вот могу отметить, что в первый раз (когда все сообщения подгружались), у меня несколько раз обрывалось соединение, и сообщения, по-видимому, загрузились не все. Думаю, что алгоритм загрузки просто загружает сообщения в прямом, а не в обратном (как надо) порядке. Ну и цикл не работает, естесственно.

Так, отчитываюсь: обновился на последнюю версию - сообщения загружаются правильным алгоритмом, но Очень медленно. Увеличил размер бандла до 60 - пошло более-менее нормально (но всё равно неторопливо)

оффлайн не пробовал, но поскольку завтра еду на дачу, то попробую обязательно, так как трафик экономить надо

>Если первый раз, то это нормально, там тысячи сообщений ведь:)
Да, понятно, но просто при этом процессе я не вижу, живая ли вообще эта закачивалка или нет :)

это сообщение было отправлено из оффлайн режима

> Кто-нить уже смотрел? Или ждёте нормальной полноценной версии? =)
Скачал, не показывает список эх, когда жму Enter, к примеру, он уходит в дебаггер, поэтому выход только через Ctrl-C

Конфиг:

; (setq *authkey* "")
(setf *node* "http://irk38.tk/ii/ii-point.php?q=/u/")
(setf *echo* (list "im.100" "pipe.2032" "lit.14" "music.14" "ii.soft.14" "ii.dev.14"))

(сам хотел себе написать на ncurses читалку, но не осилил, сложно :), пишу на tkinter)

> Нажми G и скачай сообщения.
Я долго не мог понять, почему у меня не закачиваются сообщения, а потом понял, что g должна быть маленькой буквой, а не большой (просто нажимал Shift-g) =)

> Как посмотришь, отпишись что удобно что неудобно показалось.
Поскольку использую xfce4-terminal, попасть в "Помощь" не получилось, F1 показывает справку терминала. Ну и ладно, это его косяк.

Что конкретно напрягло: когда заходишь в эху, по-умолчанию показывается первое сообщение, а не последнее, что довольно неудобно. Ещё обнаружил, что можно делать прокрутку в сообщении, которое полностью вписывается в окно терминала (а этого быть не должно всё-таки). И когда входишь обратно на экран с эхами, жмёшь g, то интерфейс чуть подвисает, и сообщения не загружаются. + если пытаешь выходить через Ctrl-C, а не через F10, то консоль превращается в кашу из букв и цифр дебаггера, а после выхода обратно командный интерпретатор (здесь имею в виду bash) просто ломается.

А вообще клиент хороший, красиво выглядит. Порадовало отображение msgid сверху, что очень удобно (в свой клиент я эту фичу ещё до этого добавил). Приятные цвета, хорошее распределение пространства рабочей области.

>> И когда входишь обратно на экран с эхами, жмёшь g, то интерфейс чуть подвисает, и сообщения не загружаются.
> Вот тут поподробнее. У себя не наблюдал пока такого, так что интересно.
1. Захожу смотреть эху
2. Выхожу из эхи по Escape
3. Жму g и одновременно клавишу вверх/вниз
Если сообщения есть, то чуть подтормозив, показывает диалог фетча, если сообщений нет, интерфейс чуть притормозил и продолжил работу дальше (кстати, так даже не видно, есть новые сообщения или нет)

> Может, отлавливать Ctrl+C попробовать?
Это и предлагаю, ncurses вроде должен уметь это делать

> Интерфейс слизан с голдеда. А голдед это наше всё.
Я ж не использовал голдед, да и вообще не фидошник. Поэтому в новинку, интересно =)

Написал для самого себя gui клиент на python+tkinter, сейчас пишу с него.
Особенности:
* Модульный: фетчер отдельно, мейлер отдельно, написание сообщений (во внешнем редакторе) отдельно, читалка отдельно. Любой компонент при желании можно заменить другим. Юникс вей
* Фетчер свой, портирован с webfetch.php. Добавить /x/t было лень, но всё-таки сделаю
* Конфиг в формате json (основные моменты как обычно + указание внешнего редактора для написания сообщений)
* Читалка основана на ii-reader-tk.py, который был мною давно написан (Рома помнит)
* Ну так, ещё по мелочи особенностей, для меня самого

Скриншот: http://irk38.tk/screen-client.png
Исходники выложу, если кому надо

> Выкладывай =)
http://irk38.tk/files/iiclient-modular.tar.gz

> А как в нем ответить на сообщение?
> Нажимаю на кнопку ответить, открывается мой редактор(kwrite), я в нем пишу сообщение. Сохраняю и закрываю редактор. Дальше ничего не происходит.

Дальше в клиенте жми кнопку "Закачать сообщения", что слева находится. Потом чуть ждёшь, и всё. Потом жмёшь "Скачать сообщения" (справа находится) и получаешь себе то, что ушло на сервер.

>Может тогда лучше обозвать как-нибудь более очевидно? Типа, "Отправить сообщения" или как-то так.
Действительно, так и сделаю. А как тебе сам клиент, какие баги нашёл?

> Багов пока не видел.
А я увидел, поэтому исправляю.

> Интерфейс жуткий.
Согласен. Зато работает =)

> Оно, кстати, умеет темы цеплять GTK/Qt?
Не умеет, это же tk. Но написать к нему gtk/qt интерфейс заместо этого несложно - клиент же модульный. Поэтому от такой читалки можно и избавиться.

Станция mira (irk38.tk) больше не гейтует эту эху. Рекомендуем переходить в ii://ii.14

I wanna check too!!!!

Checking my php testnode

Кажется, пхп нода готова :)

> Корень моего предложения прост: избавиться от суффиксов и перекатывания эх, оставив всё максимально совместимым с тем, что мы имеем.
А я предлагаю суффиксы не убирать, а сделать _необязательными_. Перекатывание тоже лучше на первое время оставить на обычные эхи, но на какую-нибудь болталку ради тестирования убрать. И ещё сделать длину msgid от $n (это может быть как 12 для совместимости, так и сколько угодно) до 40 знаков, но по дефолту оставить 20.

> * фетчинг сделать разным: забрать всё, забрать сколько-то последних сообщений в эхе, забрать всё, после уже имеющихся сообщений в локальной базе;
> Если же в конец запроса добавить /n, где n -- произвольное число, то нода вернёт последние n сообщений из указанных эхоконференций. Если в эхоконференции сообщений меньше n, то вернёт все.

Предлагаю понятие "столько-то последних" расширить: взять не обязательно последние, а n первых, от k до n и так далее. Проще говоря, как списки в питоне. "Забрать всё после определённого msgid" тоже можно сделать.

И не забыть, кстати, реализовать расширение сисопофайлов, которое ты предлагал =)

> Хоть убей не помню о чём речь. Напомни пожалуйста.
/x/file или что-то подобное. Где поинту выдаётся список файлов ноды и возможность их скачать с помощью authstr.

> Какой толк в регулируемой длинне msgid?
Просто ради совместимости. А то тут по 100500 стандартов всякие делают, что потом гейтоваться трудно. Мне, если честно, так и хочется 20 оставить.

> Сперва я сделаю отдельную тестовую ноду для обкатки технологии. Может даже не буду её сообщать с существующей сетью.
А я в таком случае опять за возрождение ветки features =) Торопиться ведь тоже не надо.

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

> PHP-нода тоже очень нужна. Мне она уже не столь актуальна, но я с теплотой вспоминаю те времена, когда она была единственным вариантом для меня.
Мимими :3, приятно такое читать =) Лично я продолжу её использовать, потому что помню каждый кусок кода в ней, и там удобно всё подряд менять/улучшать/и.т.д.

> Как думаешь, лучше сделать синтаксис один в один питоновский или упростить немного?
Думаю, лучше будет упростить

-10 - 10 последних
10 - 10 первых
10:20 - с 10 по 20
-10:5 - с десяти последних по 5

или как в сишном клиенте

l10 - last 10 messages
f5 - first 5 messages
r2:4 - from 3rd to 5th (including)

, но from -> to нужно расширить до значений с конца списка

> Может последний вариант сделать в виде 5:-10? Так будет логичнее запись запроса и неофит не будет ждать развёрнутый задом на перёд список
Я просто имел в виду, что 1 цифра - это начало, а вторая - конец. Но это скорее я неверно выразился

10:10 - 10 cообщений, начиная с десятого
-10:5 - 5 сообщений, начиная с минус-десятого

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

> Только со временем тяжко нынче - я опять человек-отдел =)
То же самое =), даже написать сюда времени иногда нет.

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

Мне тоже кажется, что обсуждения про ["хоккей" и "какие идиоты сидят на очередном околоспортивном сайте"] никому не нужны кроме него самого; аналогично наваливает скептицизм. Но для начала попробовать стоит (а вдруг, вдруг? =) ), так что фильтр на msgid пока ослаблю.

О, отлично.
ii-php пока нескоро делать буду из-за резкого недостатка свободного времени, но обязательно реализую.

Может, теперь наконец-то стоит публично сообщить о нашем решении в pipe.2032/ii.14?

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

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

> Ребилдить ли ему локальную эху или просто дописать новые полученные сообщения в конец существующего списка?
Просто дописать в конец. Порядок при прочтении у нас не важен, ибо существует repto, да и вообще.

> Оглядываясь на Fido, есть идея сделать отдельный интерфейс в цезии и скрипт в iitxt для забора нестандартной выборки и просто добавить эти сообщения в существующую базу в конец.
Добавить параметры командной строки к фетчеру iitxt, и дело с концом.

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

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

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

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

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

Избавляемся от /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