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

Сделаю в районе фикса пустых эх.

У меня подход такой к разработке: есть фиксированные версии, а всё остальное это development ветка. Я пока не могу себе позволить по времени малые циклы разработки, но замена тегов на master-ветку никак не изменит того факта, что в ветке разработчика периодически будет что-нибудь отваливаться.

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

vit01> А ещё при заходе в пустую эху (в моём случае это либо карбонка, либо favorites), клиент валится из-за скроллбара.

Проблему понял. В ближайшее время поправлю.

vit01> * фетч идёт с самого последнего сервера, который указан в конфиге (обнаружил, когда запускал скрипт отдельно)

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

vit01> Однако есть пара архитектурных проблем:
vit01> * фетч идёт с самого последнего сервера, который указан в конфиге (обнаружил, когда запускал скрипт отдельно)

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

vit01> * надо как-то узнавать, какое количество новых сообщений было скачано в ходе работы (или даже сами их айдишники) для удобной интеграции

Для интеграции с чем? Давай чтоль конкретный фичереквест, а то количество сообщений оно пишет на экран, но есть подозрение, что это не то.

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

vit01>> Фетчер начинает бесконечно запрашивать список и не выходит из цикла.

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

Отпишись как протестируешь.

vit01> Для интеграции со своими скриптами. Например, мне хотелось бы сделать Android-уведомления о фетчинге. Для этого фетчер должен иметь 3 выходных состояния: 1 - скачано N сообщений, 2 - новых сообщений нет, 3 - ошибка <название>.

vit01> Это можно реализовать либо специальным "тихим режимом", где пишется только "fetched N" или "error: text", либо заворачиванием фетчера внутрь какой-нибудь питоновской функции.

Тихий режим можно организовать вполне.

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

Подумываю я свою домашнюю станцию вывести в нашу сеть на двухсторонний обмен. Есть ли у многоуважаемго Олла возражения по этому вопросу? =)

В честь моего интереса к сабжу на station13 появилась скрытоэха edgar.allan.poe с его рассказами и стихами. Эха пока в процессе наполнения. Порядок содержимого таков: по годам (каждый год в алфавитном порядке) сперва рассказы, а в последствии добавлю и стихи.

На гейт ставить пока ни к чему, пожалуй, но можно настроить клиенты и почитать =)

vit01> Обнаружил теперь регрессию в фетчере:
vit01> Если запустить без аргументов, то выдаёт
vit01> ====
vit01> Traceback (most recent call last):
vit01> File "./fetcher.py", line 116, in <module>
vit01> node["node"] = node_addr
vit01> NameError: name 'node_addr' is not defined
vit01> ====

Вот спасибо. Буду разбираться.

vit01> Ещё минус, что при отсутствии поддержки /u/e начинается фетч с самого начала, с 2014 года

Если нет расширенной u/e, то он работает в старом режиме. Пилить тот костыль, который был в цезии, мне очень не хочется.

vit01> И да, если выбрать твою ноду, то он почему-то долго думает (тормозит) на этапе определения /x/features

Вот это странно, но это скорее нода тупит. Ты имеешь в виду таверну или станцию13? Если первую, то там могут быть небольшие затупы на любом этапе.

vit01> Минуты две думал, кто такой Олл, и только потом допёр, что это вообще-то All :)

=)

vit01> // могу хоть сейчас добавить

Через тебя пока действительно лучше. Ты если что оперативнее отреагируешь, так как я пока не всегда могу зацепиться за сервер со станцией13. Так что буду благодарен.

Поинты мои, в таверне действительны ваши auth-ключи от станции13. Можете постепенно съезжать.

vit01> Фетч уже идёт, проверяй работу.

Привет, сетяне, вам из небольшой таверны, где грубая деревянная мебель компенсируется тёплым светом множества свечей и потрескиванием дров в камине. В углу возле большого окна сидит бородатый дядька 94 килограмм весом и заваривает ароматный чай в ожидании посетителей.

vit01> Пусть Андрей сам сначала добавит (ведь скрытоэха). А так как-то странно подобные вещи прятать. Если годный контент есть, то пусть его будет видно.

Меня смущает разве что юридический вопрос. То, что права на сами произведения уже давно в Public Domain это ясно, а вот с переводами как дела обстоят неизвестно.

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

Так ведь ни одно сообщение 64 килобайта не превышает. С другой стороны, base64 даёт некоторую избыточность, но как её вычислять? Даже в древнем фидонете ограничение было 64 килобайта. Это без всякого избыточного кодирования и в однобайтной кодировке.

>> А архива за 2014 год всё-таки нет. http://alicorn.tk/ii-old/ii-point.php?q=/
Difrex> Эхи есть в list.txt? У меня не добавлена нода alicorn.tk. Ща сделаю.

На аликорне, вроде, всё на виду.

>> Если наберёшь в амбреллу, например, echo "0L/QvtGF0L7QttC00LXQvdC40Y8g0YHRgtGA0LDQttCwCg==" | base64 -d
Difrex> ЛОЛ, ржу :D

Чего только люди не делают ага =)

В догонку:
* Теперь исходящие файлы едины для всех нод. Текущая выбранная нода в клиенте влияет только на то, с какого адреса будет отправлено сообщение.

Для обновления необходимо скопировать всё содержимое произвольной директории из out/nodename/ (включая .outcount) в директорию out/ и удалить все директории с именами нод.

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

Небольшие изменения.

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

В фетчере:
* исправлен баг в фетчере, приводивший к ошибке при вызове фетчера без параметров;
* исправлен баг в фетчере, приводивший ко входу в бесконечный цикл в случае, когда локальный индекс эхи не пересекается с индексом на ноде.

Изменения уже в master-ветке на гитхабе.

АЛЯРМ! На всякий случай. master-ветка является веткой разработчика и при внедрении новых фич может содержать баги и регрессии. Если хотите стабильной работы без отписывания багрепортов, используйте фиксированные версии (они тоже не идеальны, но всё же). Единственное но на момент фиксации версии 0.2 были баги в фетчере, но можно взять фетчер из master-ветки.

AL> Оставим как есть и я буду тогда сносить creepy.14 и edgar.allan.poe или пересмотрим стандарты?

Ещё в lit.14 есть большие сообщения. В общем, я вижу три варианта дальнейших событий:

1. Мы расширяем допустимый размер кодированного сообщения до 84 килобайт, что даст нам 64 килобайта полезной нагрузки.

2. Мы не трогаем стандарт, глушим и перебираем (видимо, я, ведь я эти толстые сообщения заслал) проблемные эхи.

3. Не трогаем стандарт и оставляем проблемные эхи как есть.

Больше вариантов я пока не придумал. Что думаете, товарищи?

Исправлен досадный баг, приводивший к падению клиента при построении списка исходящих сообщений.

Баг являлся регрессией в следствии отката к единой базе исходящих.

Исправлен баг в iing с неверным определением размера входящих сообщений.

В общем, увеличение объёма примерно на треть. То есть на 64К кодированного сообщения приходится всего 48К полезной нагрузки. Оставим как есть и я буду тогда сносить creepy.14 и edgar.allan.poe или пересмотрим стандарты?

Исправлен баг в iing с неверным определением размера входящих сообщений.

Шарик, ты балбес.

Приношу извинения за поток сознания. Не разглядел сперва.

Тогда предлагаю идти просто: сообщения добавить в блеклист сообщения:

dC7OnJorzWbuIFHwQGSV
QtejFXhvltgGk2HQAMpA
0k6IPR9lTJSKbFHPN9q5
sPn1SzQ3yumOmkabTJNh
LaXI0wDMJUtzT5r2InP7
pxV4dz8m1TzwSRANrynE
HHVbGQxkeywkNahLo8GT
bQcnbAcxQHYnivn8i1Gq
9Pp1jKkFX1ujg1hvFY4k
zzGJqgpS7HJckntZcXqq
NnK9BULgARR4lvyZlgX0

Я их переразобью в соответствии со стандартом и зашлю по новой.

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

btimofeev> Можно в сабж добавить кейбиндинги для "отметить ветку прочитанной" и "отметить все сообщения прочитанными"?

Для этого придётся сделать сперва сообщения непрочитанными/прочитанными. А веток в цезии вообще нет, так как не в духе сети.

AL> Тогда предлагаю идти просто: сообщения добавить в блеклист сообщения:

AL> Я их переразобью в соответствии со стандартом и зашлю по новой.

Сообщения в блеклисте. Соответствующие произведения переразбиты и переотправлены в эху.

btimofeev> Я имел ввиду эху, не правильно выразился.

Эху можно промотать в конец клавишей End.

vit01> Эха со статистикой прокинута.

Хорошо. Правда там в эхах немного бардак, но это дело поправимое.

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

На гитхабе оно сразу в двух репах у меня. В цезии и в ноде.

Переписал скрипт сбора статистики по эхам (на этот раз на питоне).

Эха ii.stat имеется как на таверне, так и на станции13.

PS: Скоро скрипт можно будет забрать с гитхаба из репов iing и caesium.

// Хочу этот скрипт запустить в автопилот на таверне в скорости, если ничего не помешает.

vit01> Обнаружил на сабже одно порченное сообщение в ii.test.14 ii://FbYeDw3FpA64o9g2ga20

Спасибо. Посмотрю.

vit01> Ещё более странное дело с /x/file. Подключившись к Таверне через свой клиент, обнаруживаю, что не могу получить список файлов.

vit01> и получаю ... пустую строку, хотя по идее здесь должен был быть список файлов. Если добавить параметр filename, то всё работает.

Что странно, так как я спокойно его получаю. Надо будет снаружи проверить, но это только в среду смогу.

vit01> Это не первая странность с /x/file. Проверив через браузер, обнаруживаю, что при запросе /x/file/filename выдаётся содержимое файла (хотя по стандарту так не должно быть)

Вот тут поподробней. Судя по стандарту он так и должен себя вести в случае с публичным файлом.

vit01> но при этом при запросе /x/file/random_string/filename нода шлёт пустоту, хотя файл публичный. При неверном authstr нода должна запретить вывод скрытого файла, но не публичного.

Вот это тоже неоднозначная ситуация, но можно и предложенное тобой поведение добавить.

vit01> Такие вот дела.

ЗЫЖ Таверна это вообще загадочное место. Иногда здесь случаются поистинне мистические вещи.

vit01> # на предыдущем сообщении, на которое сейчас отвечаю, регулярки веб-интерфейса таверны сломались

Вот это уже пофиксил. С остальным пока не могу разобраться.

vit01> Что ж, лучше поздно, чем никогда.

Спасибо тебе, добрый человек =)

vit01> Неа. Судя по стандарту, третьим параметром всегда должна идти authstr.

vit01> Если человек сделал запрос /x/file/string, то нода должна проверить правильность authstr и вывести на экран список файлов, причём не только публичных, но и "приватных".

vit01> Мы же при формировании стандарта договорились сделать возможность размещать как файлы только для поинтов, так и файлы для всех остальных.

А как быть, если у пользователя отсутствует поинт на ноде? Не надо забывать про GET-запросы всё таки.

Я сейчас туда заглянул и ужаснулся. x/file надо переделывать с нуля, можно сказать. Что-то я там такую чушь наворотил. Только сперва таки надо разобраться что пользователь должен слать в GET-запрос.

vit01> А так разве медленно и непонятно? При нынешнем подходе оно хотя бы работает и выполняет поставленные задачи.

Ну так и без расширенной u/e оно хотя бы работало. И выполняло поставленные задачи. Надо думать об удобстве.

vit01> Можно поменять местами pauth и filename, но в таком случае будет неудобно получать список файлов.

Да там одно простое условие. Просто я писал как всегда перед сном и потому там лажа у меня в коде. Но я не настаиваю. Стандартом по факту занимаешься ты. Если считаешь, что надо всегда указывать authkey, даже если его нет, то сделаем так. Просто я и так и этак смотрю на такой подход, а он мне всё равно не нравится.

Пожалуй, сделаю пробно в таверне то, о чём я говорю, а ты посмотришь. Если не понравится, то сделаю с обязательной авторизацией.

vit01> Возьмём, к примеру, сообщение из пайпа про фоточки с прогулки: ( ii://flYdgHRQTACMOc9kW4KW )

vit01>> Если что, вот браузерная ссылка: http://ii-net.tk/ii/ii-point.php?q=/x/file/none/2016-04-16.tar.xz

vit01> Когда человек запрашивает публичный файл (даже не являясь поинтом), то он имеет право ставить в поле authstr всё, что захочет. В данном случае стоит "none", но можно хоть "blablabla" поставить, и mira station всё равно отдаст файл. Если файл публичный, то нода authstr просто не будет проверять.

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

Лично я, когда предлагал эту схему, предполагал переменное количество параметров в зависимости от того, что пользователь передаёт. Чтобы хоть wget'ом, хоть через браузер мог быстро и понятно получить файлы.

// Я ещё подумаю, а пока x/file в таверне можете считать нерабочей.

vit01> Вот почесал репу и придумал вариант, который устроит нас обоих. Можно разделить /x/file на 2 схемы: одна для списка, другая для скачивания.

Сделал в таверне такой вариант. Попробовал его и с GET и с POST запросами. Понравилось. Пока из всего, что мы надумали, этот вариант мне нравится более всего.

vit01> Проблема в том, что нода должна как-то различать authstr и имя файла. Вот отправил ты запрос /x/file/string, а нода должна думать: ты поинт и хочешь получить список, или ты файл с именем string скачать хочешь? Забавные вещи будут выходить, если в конфиге есть и файл с таким названием, и поинт с таким authstr.

Вероятность того, что authkey будет хотя бы напоминать имя ркального файла болтается где-то в районе нуля. У нас и коллизии в msgid могут запросто возникнуть, но с исчезающе малой вероятностью. Потому я считаю, что простой проверки по поинтлисту достаточно, чтобы определить что это пользователь передал.

vit01> Вот почесал репу и придумал вариант, который устроит нас обоих. Можно разделить /x/file на 2 схемы: одна для списка, другая для скачивания.

vit01> ====
vit01> GET /x/filelist
vit01> # публичные файлы

vit01> GET /x/filelist/pauth
vit01> # публичные + приватные файлы, если authstr верный

vit01> GET /x/file/filename
vit01> # публичный файл или ошибка

vit01> GET /x/file/pauth/filename
vit01> # приватный (или публичный) файл или ошибка, различие
vit01> # с предыдущим запросом определяется по количеству параметров
vit01> ====

Вот такой вариант стройнее и красивее. И надо решать вопрос пока ещё этой фичи толком нет нигде.

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

Я тут понял на примере того же инстеда, что разработка стандарта должна опираться на два столпа: непротиворичивость и диктаторства. Иначе начнётся элементарный хаос. Потому я и признаю авторитет, потому и мусолю эту тему с файлами так муторно.

vit01> Так изменяем или не изменяем саму схему? Вообще, POST у тебя точно сломанный, а насчёт GET надо сейчас до конца решить.

Я сегодня постараюсь найти время на исправление ноды.

vit01> Ну а что бы ты предложил в альтернативу? Тут два варианта: либо GET-запросы не работают с приватными файлами, либо оно выглядит "некрасиво".

Видимо, у нас разное представление о "прекрасном" просто. Мне нравится идея, что третий параметр может быть или authkey или именем файла и нода в зависимости от этого отдаёт соответствующую информацию.

vit01> Мне-то всё равно, у меня клиент в любом случае работает только через POST (а кроме нас двоих сабжем в принципе никто не пользуется), так что пробуй, решай, как удобнее будет.

Да не. Давай уже определимся. С учётом того, что ты с моей точки зрения больший авторитет имеешь в вопросах стандарта, так как ты больше для него и нашей сети сделал, твоё видение более правильное =) Просто пропиши этот момент в стандарт более однозначно, а я уж буду им руководствоваться при правке своей ноды.

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

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

vit01> Насчёт POST прошу уточнить, т.к. это важно. Мы делаем примерно такой вариант?

vit01> ====
vit01> POST /x/filelist
vit01> # публичный список

vit01> POST /x/filelist pauth=string
vit01> # приватный + публичный список, либо только публичный, если неверно

vit01> POST /x/file pauth=string, filename=string2
vit01> # содержимое файла, если pauth верный или filename публичный
vit01> # ошибка, если файла не существует
vit01> # ошибка, если файл приватный и pauth неверный

vit01> POST /x/file filename=string
vit01> # содержимое файла, если публичный
vit01> # в ином случае ошибка
vit01> ====

Вроде да. По крайней мере тесты в таверне дают именно такое поведение и именно так я понял изначальный посыл с двумя схемами.

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

Не беда. Я вот вообще на два дня из реальности выпал.

vit01> Хотел бы ещё насчёт этого файлика узнать: почему у тебя на ноде в /x/file его нет?

Потому что забыл выложить. Дырявая моя башка.

В таверне лежит, а станция13 без x/file пока что. Надо обновлять.

Надо бы ещё запись про http://ii.difrex.ru/ сделать и выпустить уже публичный сетевой ноделист. А то чо как лохи без ноделиста сидим? =)

vit01> В сабже уже неделю висит пулл-реквест для андроидопатча.

Смержил.

Сабж обзавёлся списком сообщений в эхе, удобным для прочтения таких конференций, как ii://lit.14, ii://creepy.14 и ii://edgar.allan.poe.

В целом, вебинтерфейс ещё пилить и пилить, но такую штуку я давно хотел для веб-интерфейса.

Небольшие нововведения в сабже:

* Добавлена подсветка URL. ВНИМАНИЕ! Необходимо добавить параметр url в файл цветовой схемы;
* Если в конфиге установлена несуществующая тема, то будет загружена тема по умолчанию.

Дабы не плодить сущности в гите, создал отдельный репозиторий под свои скрипты для ii/idec.

https://github.com/spline1986/idec-utils

И ещё:

* Исправлен баг, приводивший к падению при попытке прочтения отсутствующего в базе сообщения;
* Добавлена возможность получить с ноды отстутсвующее в базе сообщение.

Последний пункт следует объяснить. Предположим, что у нас в индексе фигурирует msgid, но сообщения при этом в базе нет. Цезий в таком случае сообщит нам в режиме чтения, мол такого сообщения нет. В этом случае будет доступна клавиша G (по умолчанию), которая вызовет функцию скачивания текущего сообщения с ноды.

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

vit01> archive.py, clean.py и stat* оказались бы полезны и в ii-db-utils.

Бери да и всё =) Только отпишись сюда, если вдруг багфиксы или какие изменения.

vit01> Хорошо бы эти репозитории вообще как-нибудь объединить, потому что и там, и там третий питон.

Я думал над этим, но, например, мой freq.py мне нравится больше, чем твой xfileget.py, хотя они и очень похожи (а сохранения файла я вообще у тебя утянул), а каши при этом не хочется.

vit01> Клонировал в цезий на компьютер. Сервер нагрузку выдержал (да и разве можно было её НЕ выдержать?).

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

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

Там SSD на 4 гига =) Но сдохнуть может что угодно, как показывает практика. Например, очень знатно пухнут электролитники, пыль устраивает КЗ и вырубает ключи в районе процессора, выжигая этот самый процессор. Всякое встречал в своей практике.

vit01> Если ты ставил его как сервер, то с этого и следовало начинать, наверное. Вот у меня на нетбуке хорошая вайфай-карта и драйвера отменные (свободные на AR9285), но если бы пришлось ставить его 24/7, то даже такой удаче доверять не следовало бы.

Тем не менее почти год не было проблем. Так что довольно странно, что они сейчас появились.

Провёл некоторые работы в таверне. Просьба попробовать клонировать какую-нибудь толстую эху, например ii://lenta.rss. Просьба актуальна до завтрашнего дня. Завтра я уже и сам успею потестировать таверну снаружи более плотно.

// Есть ненулевая вероятность, что сервер таверны доживает своё. Жалко будет, если умрёт. Машинка героическая. Это Asus EeePC 701 4G (да-да один из самых первых нетбуков в мире), приобретённый в славном 2008-м году ещё до кризиса. Машинка служила и служит верой и правдой все 8 лет своего пребывания у меня. Сначала как основной нетбук, который выручал и в кафе и в лесу и на чужих дачах, потом это был кухонный нетбук жены для гугления рецептов и чатика во время готовки. В последний год это домашний сервер. Не взирая на малый экран и скверную клавиатуру это весьма надёжный друг.