AL> В документации не хватает информации о стандартных ответах ноды.

Ты имеешь в виду msg ok: <msgid> или error: blablabla?
У нас эти самые ответы вообще в стандарт не включены. Могу, конечно, взять те, которые сейчас в PHP-ноде, но для остальных нод они могут отличаться.

AL> // Антиэхотаг, я так и не решил как лучше организовать процесс фетчинга. Просто забирать последние N сообщений индекса мне не нравится.

Именно для этого существует схема /x/c, которая пока не поддерживается в таверне, но зато сильно ускоряет процесс фетча. Вперёд за нанотехнологиями =)

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

AL> Умеет ли он клонировать эхи и есть ли возможность задавать все параметры (ноду, эхи, клонируемые эхи) через CLI? А то я подумываю не велосипедить, а прикрутить к цезию твой фетчер.

Через GUI клонирование только костылём. По факту фетчер - это всего лишь одна функция:

def fetch_messages(adress, firstEchoesToFetch, xcenable=False, one_request_limit=20, fetch_limit=False, from_msgid=False, proxy=None, pervasive_ue=False, callback=None, cut_remote_index=0):

Вызывая её только с первыми двумя параметрами, ты получаешь тот самый clone.
Думаю, CLI-морду для всех возможностей ты вполне можешь реализовать сам. Если что, спрашивай.

И тут я посмотрел на неё и понял, что, оказывается, немного ввожу народ в заблуждение.

Параметр from_msgid не работает, потому это всего лишь заглушка (а в стандарте подходящего расширения просто нет, несмотря на то что сервер ii-php его поддерживает).

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

Добавил в фетчер (и в GUI-конфигуратор) сабжа возможность принудительной обрезки удалённого индекса. Такую же функцию реализует Цезий, работая со старыми станциями на 0.3, которые не поддерживают расширенный /u/e

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

В сабже починил ответ на сообщения из окна "стены текста"

В настройках станций добавил пункт "Настроить всё автоматически". Когда пользователь нажмёт эту кнопку, клиент заботливо проверит поддержку всех схем через /x/features и сам расставит все галочки для расширений в зависимости от их поддержки.
А если /x/features сообщает о наличии list.txt, то ещё и загрузит список эх с ноды (аж минус один клик!).
Если нет поддержки расширенного /u/e, то поставит принудительную обрезку индекса на 50 сообщений (как в Цезии).
Также кнопка автонастройки проверяет одну типичную опечатку для новичков (забывают слэш в конце адреса ноды) и исправляет её.

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

vit01> Через GUI клонирование только костылём.

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

vit01>> 3. Расширенный /u/e используется и там, и там. Различие лишь в том, что оптимальное значение на клиенте - это 50-100, а на сервере - немного больше. Mira station фетчит каждого аплинка со смещением 200. Уже как очень долгое время.

AL> Эту практику я считаю приемлемой, если нас не интересует гарантированное получение всех новых сообщений.

Без обид, но у тебя плохая память :)
В моём фетчере эта проблема уже решена. Передаёшь параметр pervasive_ue=True, и ни одного сообщения потеряно не будет.

Алгоритм:
Запрашиваем последние -N. Если все из них новые, то запрашиваем -2N:N и так далее, подсовывая в начало.

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

AL> 2vit01: Да я могу взять твой навороченный фетчер, но мне он показался достаточно сложным (не в духе нашей сетки, так сказать). Хочется максимальной простоты а-ля изначальный ii, но с шахматами и гимназистками.

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

vit01>> Запрашиваем последние -N. Если все из них новые, то запрашиваем -2N:N и так далее, подсовывая в начало.

AL> У меня на данный момент так же точно происходит (по крайней мере при построении индекса). Фигня случается, когда одна и та же эха забирается с разных узлов. В таком случае этот подход приводит к потере сообщений из-за разного порядка сообщений на разных нодах.

Вижу только единственный вариант, при котором такое может произойти.

Есть нода1 и нода2. У клиента стоит /u/e, предположим, на 50 сообщений.
В течение 10 минут на ноде1 появляются сразу 50 сообщений. В то же самое время на ноде2 появляются 10 сообщений. После этого нода2 гейтует ноду1, забирая те 50 сообщений.

Итого на ноде1 - 50 новых, а на ноде2 - 60 новых.

В этот самый момент подключается клиент и начинает фетчить сначала первую, затем вторую.
Так как у него лимит стоит 50, то с первой ноды он забирает 100 записей индекса и успокаивается. На второй ноде он обнаруживает 50 сообщений, которые у него уже есть в базе, и не трогает её дальше.

Да, действительно, потери. Но тебе не кажется, что такой интенсивный трафик в одной единственной эхе за такое короткое время - это _слишком_ маловероятно?

Но это ещё не всё. Предположим, вышеописанная ситуация каким-то сказочным образом осуществилась.

Дальше нода1 гейтует ноду2, забирая у неё недостающие 10 сообщений (мы же не забыли, что сервера оптимизации не используют, да?). Клиент фетчит ноду1, и недостающие 10 сообщений также к нему приходят. Всё разрешилось само собой.

AL> Определение смещения для расширенной схемы u/e мы можем хранить как константу (или передавать как константу в качестве параметра), а можем вычислять из результата работы схемы x/c.

AL> На стороне клиента ещё возможны костыли вида каждому аплинку по базе (хотя мне эта затея и не нравится), но на ноде мы уже так делать не можем.

Для начала не надо мешать мух с котлетами, то есть сервера с клиентами.

1. Вычисление смещения из результата /x/c - это порочная практика. Её никто никогда не предлагал и не реализовывал.

2. На сервере /x/c не нужен. Более того, ни один серверный фетчер его не поддерживает. Эта схема необходима только для того, чтобы клиенту не фетчить creepy.14, mlp.15 и прочие питоны, в которые пишут не больше раза в неделю. Самая частая работа /x/c - это выдать на экран надпись "новых сообщений нет".

3. Расширенный /u/e используется и там, и там. Различие лишь в том, что оптимальное значение на клиенте - это 50-100, а на сервере - немного больше. Mira station фетчит каждого аплинка со смещением 200. Уже как очень долгое время.

AL> Пока лучше достаточно большой минимальной длины запрашиваемого индекса я не придумал. Но это всё равно достаточно мороченный вариант. Может действительно имеет смысл просто забирать индекс фиксированной длины и не заморачиваться на лютую оптимизацию трафика (что такое +- несколько десятков килобайт в наши дни?).

Так и надо. Для гейтоскриптов вообще можно и не использовать кучу оптимизаций.

Чтобы все были счастливы, надо

1. Делать ровно один запрос /u/e вместо того, чтобы опрашивать каждую эху
2. Добавить в Цезий поддержку /x/c, чтобы не фетчить все 40 эх из подписок, когда новые сообщения только в пайпе или в новостях (или когда их вообще нет).

Этих двух пунктов достаточно и для скорости, и для комфорта.

AL> На пробу можно взять мою версию (непричёсана и как всегда с дублирующим кодом пока) тут http://spline-online.tk/stuff/fetcher.py можно просто подложить её цезию и она будет работать.

И она работать пока отказывается.
https://ii-net.tk/ii/files/I7D9Pr9GzoFkojC1mSix.png

AL> Ошибка странная. С какой нодой возникает?

Видимо, с самой первой, mira station. От изменения подписок ошибка не уходит. Скинул конфиг на email

vit01> Реализую-ка у себя тоже этот хак с /x/c, чтобы от прогресса не отставать.

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

vit01>> Дальше нода1 гейтует ноду2, забирая у неё недостающие 10 сообщений (мы же не забыли, что сервера оптимизации не используют, да?). Клиент фетчит ноду1, и недостающие 10 сообщений также к нему приходят. Всё разрешилось само собой.

AL> Я хочу оптимизацию на серверах применять %) Отсюда и наступление на грабли.

Тогда ничего против не имею. Надо как-то лучше друг друга понимать учиться :)

Реализую-ка у себя тоже этот хак с /x/c, чтобы от прогресса не отставать.

>> И не просто шевелится, а вполне себе ходит :)
gadfly> И много тут народу?

4 человека ровно. vit01 (т.е. я), spline (теперь он уже Andrew Lobanov), Difrex, иногда бывает поинт btimofeev.
По факту у нас сейчас серверов больше, чем людей.

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

gadfly> Раз мой клиент завелся без изменений, значит протокол не сильно меняли. Но расширения протокола видел, да. Был-таки форк? Была драма?

Суть форка была только в смене названия и в добавлении расширений для экономии трафика. В остальном совместимость с ii гарантируется.

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

Драма была и не одна :) Читать эхи ii://pipe.2032 и ii://ii.14

gadfly> ОНО ШЕВЕЛИТСЯ

И не просто шевелится, а вполне себе ходит :)

С возвращением, привет.

// Заглядывал на сайты с доками?

AL> И ещё дебаг опцию надо отключить.

И зря. Всегда включаю дебаг, это одна из самых нужных настроек.

Ну а так новая версия работает, большое спасибо. Теперь ждать меньше буду с мобильным интернетом.

AL> Я ещё в 2014-м понял, что я средоточение мирового зла =)

Не ты один; именно поэтому у нас теперь Секта Плохих Парней, а не просто ии-шечка ;)

> Из того, что помню, была драма, из-за которой мы решили поменять название.
gadfly> Опять "вы изговнякали моё ii"? Форкнулись и разбежались. Изначально разные цели и идеология.

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

Рома напридумывал за время твоего отсутствия 2-3 новых проекта, которые не были совместимы с ii, и ушёл сам. А мы уже потихоньку определились, чего хотим от форка и какие цели преследуем.

> Через некоторое время были срачи по поводу нового цитирования.
gadfly> Этого вообще понять не могу.

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

gadfly> Я с точки зрения социологии и психологии интересуюсь :)

Тут уже, извини, не специалист :)

> Драма была и не одна :) Читать эхи ii://pipe.2032 и ii://ii.14

gadfly> Много букв :/ Можно краткое изложение для троешников?

Из того, что помню, была драма, из-за которой мы решили поменять название. Через некоторое время были срачи по поводу нового цитирования. Ну а самый последний из неприятных случаев здесь: http://ii-net.tk/ii/ii-web.php?echo=pipe.2032&page=95

Ровно два месяца живём мирно и без происшествий.

Вообще, не советую забивать этим голову, т.к. мы ведь не для того здесь сидим, чтобы гадости читать, верно?

gadfly> Создатель, кстати, тут появляется вообще?

Раньше появлялся регулярно. Последний раз - ровно 2 месяца назад. Если хочешь с ним связаться, то тебе сюда: http://gk11.ru/

gadfly> И я всё-таки задам этот вопрос: каковы нынче цели проекта (форка)?

Вся суть проекта изложена на главной странице документации: http://ii-net.tk/idec-doc/
Да, именно в пункте "Что мы можем вам предложить".

gadfly> Пока мне всё видится неким социальным экспериментом.

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

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

Просто нас здесь очень мало, вот и всё. К этому давно все привыкли.

Ничего страшного. Mira Station и так фетчит обе твои ноды.
А вот с http://ii.difrex.ru какие-то странности происходят.

Некоторое время назад эта нода при каком-то пределе количества msgid в эхах начинала пропускать msgid и сами названия эх из отдаваемого индекса /u/e

А конкретно сейчас в эхе habra.16 (http://ii.difrex.ru/habra.16) там можно наблюдать кучу пустых сообщений, на которые ругается мой фетчер.

AL> Для узких терминалов (например, телефонов) теперь урезается отображаемая информация для более адекватного внешнего вида.

И после этого наверху не отображается msgid. Как теперь с телефона блэклист наполнять или сослаться на какое-нибудь сообщение?

// надо бы доработать набор патчей, т.к. некоторое уже неактуально; напишу, как сделаю

AL> Это, как и отображение адреса отправителя будет отображаться в message box'е по хоткею, но пока просто спрятано да.

Нужно всё это реализовать. А то переворачивать телефон для такого очень неудобно.

AL> Надо там многое перелопатить да. Но пока до задуманного функционала то руки не доходят.

А какие у тебя планы по Цезию? (если исключить sqlite и автоподписки).

Могу подкинуть одну вещь, которой лично мне очень не хватает.

Взгляни вот на этот скриншот: http://ii-net.tk/ii/files/8U3Tvw3tYrmE7yL19HwG.png
Здесь видно ссылку. Эту ссылку выделить и копировать пальцами практически невозможно. Встроенная фича Termux для открытия ссылок не помогает, потому что обрезает ту часть, которая ушла на новую строку (6.apk в данном случае). Из-за этого, если хочется перейти посмотреть на полную новость, приходится открывать веб-интерфейс и искать нужное сообщение там.

Если как-то решишь эту проблему, то это будет огромная экономия времени для любителей читать RSS-ки.

AL> Что поделать? Дань времени.

Tor Browser - не работает;
Elinks - не работает;

Первый отключает внешние шрифты ради безопасности. Про второй и так всё понятно. Специально зашёл и проверил.

AL> Но не картинки же туда пихать. Это ещё хуже. А простые надписи по нынешним меркам слишком уж невзрачно будут смотреться.

Для картинок можно поставить alt text, и если браузер их отображение отключил, то юзабилити не пострадает. Для шрифтов так сделать уже нельзя.

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

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

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

AL> (посмотрю как оно будет выглядеть на медленном интернете, но вообще странички легковесные, а awesome-font кешируется.

О нет! Только не Awesome Font! Есть пользователи браузеров, которые принудительно ставят свой собственный шрифт на все страницы, и сайты перестают нормально отображаться. Нехорошо.

Цветовая схема немного мрачноватая; лучше, наверное, опять вернуть Solarized или просто подобрать погармоничнее. Но это уже личные эстетические придирки.

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

AL> Блин. У меня от твоего blacklist.txt станция13 чуть ласты не склеила =) Надо бы её обновить. А то фиг знает какой давности там всё.

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

Кстати, там же ещё "админ-панель сисопа" есть. Загляни туда первым делом. Там же можно почистить базу одним кликом и прочие полезные штуки сделать.

А давайте устроим чистку по чёрным спискам!
Blacklist.txt на Mira Station, например, уже разжирел. Но в одиночку чистить боюсь, потому что могут налететь с других станций сообщения.

Если есть сомнения, то можно добавить ЧС в индекс клиента и посмотреть, что будете удалять. Большинство, конечно, пустые, но всё же.

AL> // Вот он недостаток just for fun. Вместо того, чтобы добавить нужные фичи я пишу какую-то ересь.

Верно. Лучше бы юзабилити пилил :)

AL> P.S.: Кто мне скажет почему при этой фиче существенно возрастает время выхода из эхи?

Может быть, из-за функции rescan_counts, которая должна каждый раз при выходе считывать файлы всех эх и парсить их для подсчёта количества?

AL> * Объединил отправку и получение сообщений. Фетчеры теперь носят гордое имя мейлеров.

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

Например, человек решил что-то написать. Потом думает: "Завершу-ка я свой рассказ через пару часов, когда мысли в голове оформятся". Сохраняет недописанное до конца сообщение в исходящих и успокаивается.

Как ему в перерыве этих 0-2 часов читать роботов и других пользователей без отправки своей незаконченной мысли?

// Что-то последние изменения в Цезии совсем не нравятся. Придётся второй раз форкаться, наверное.

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

AL> Ситуация более редкая, чем обратная. От этого и отталкивался.

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

AL> Хм. Из необратимых пока только мейлеры, вроде. Остальное можно сконфигурировать. Не?

А как же msgid в заголовке? Файлы клавиш можно сконфигурировать, но залезать в конфиг при каждом обновлении (а ведь ещё иногда и git merge делать приходится) очень неудобно. Патчи для андроида уже протухли, и нет гарантии, что через 2 дня они не потеряют актуальности снова.

Ещё у меня свои хотелки есть. Тот же парсер ссылок давно хочется: он позволит время при чтении экономить.

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

Вроде бы, это произошло из-за каких-то неполадок у Ростелекома (на основном канале).

AL> На тему мейлеров. Никто не мешает вернуть фетчеры. А поддержку отдельного сендера я впилю. Так что действительно ли необходим форк?

Но их же ещё возвращать надо. То есть специально лезть в старое дерево, расчехлять фетчер и подменять строку в конфиге.

Либо можно сделать компромисс. Добавить в конфиг строку

behaviour preload (отправка и фетч одновременно)
behaviour keep-outbox (старое "раздельное" поведение)

AL> Кстати, сказал бы конкретно что не нравится в новом цезии. Обсудили бы.

Да, ещё забыл. Про отображение msgid и про keys-файлы всё ясно, но есть ещё одна неприятная особенность.
Фетчер (теперь уже мейлер) не умеет скачивать сообщения со всех станций одновременно. То есть он берёт только последнюю станцию из конфига, если их несколько.

AL> Вернул фетчеры. Отправка сообщений отдельной клавишей работает, если в конфиге указана опция send, содержащая вызов сендера (см. caesium.def.cfg).

Спасибо. Исправь ещё баг в keys.py. Ты там удалил комбинацию s_send, а вернуть назад забыл. Клиент падает при запуске.
// почту проверь ещё

vit01> Просто "раньше же всё работало", а теперь получается, что важная особенность сломана.

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

То, что отправка и получение сообщений являются _разными_ действиями - это нелогичное поведение? Круто, что сказать.
Ладно, если бы ты назвал это дело "Транзакция с сервером", тогда это можно было считать логичным.
Но когда пользователь выбирает именно "Скачать сообщения", то совсем не логично, что клиент вдруг начнёт сливать серверу все черновики.

А насчёт "раньше всё работало" я имел в виду все упомянутые фичи, а не только конкретно эту.

AL> Я не могу и не хочу контролировать форки и влиять на них. Сливать же форки я тупо ленюсь =)

Пулл-реквесты или Issues подойдут? Могу их присылать почаще, если ты будешь смотреть, конечно.

AL> Про msgid вообще не понял, если честно.

Процитирую тогда:

AL>> Для узких терминалов (например, телефонов) теперь урезается отображаемая информация для более адекватного внешнего вида.

vit01> Ээ, теперь наверху не отображается msgid. Как теперь с телефона блэклист наполнять или сослаться на какое-нибудь сообщение?

AL> Это, как и отображение адреса отправителя будет отображаться в message box'е по хоткею, но пока просто спрятано да.

Пока спрятано. До сих пор спрятано. Так что опять придётся чинить и патчить всё самому.

AL> Проще тогда запилить черновики отдельно. Бо это сильно разные фичи.

Можно и так сделать. Просто "раньше же всё работало", а теперь получается, что важная особенность сломана.

AL> Парсер ссылок будет после фиксации 0.3. То есть через недельку-другую хочу заняться.

Вот. Значит, что нескоро. Поэтому и хочется сосредоточить своё внимание на этом, чтобы не ждать по две недели.

Файл клавиш протестирую на андроиде в течении пары часов и отправлю.

AL> Что про сабж, кстати, скажешь?

Лично я не пользовался им и даже не тестировал. Во-первых, оверхэд при парсинге (и потребление ОЗУ, т.к. надо держать всю эху целиком, а не только индекс). Во-вторых, уже давно написаны ii-db-utils и IDEC-utils, которые совместимы только с "классикой".

Понятно дело, что оно кому-то будет нужно, если ты это добавил.

Ошибкой считаю то, что ты сделал 2 отдельных мейлера-фетчера для новой базы. Лучше создать единый интерфейс и вынести все функции доступа к базам туда (указывать нужную исключительно в конфиге). Прикладные программы вроде фетчера и самого клиента вообще не должны иметь к базе никакого отношения.

AL> Я бы не сказал, что такой уж оверхэв, бо держать в ОЗУ пару-тройку мегабайт и при этом не иметь почти 30к мелких файлов в одной директории это более правильно, чем держать маленький индекс в памяти и держать кучу файлов. В любом случае, если вдруг на машине не найдётся пары лишних мегабайт в ОЗУ, можно использовать и старый формат.

Дело даже не столько в ОЗУ. Проблема в том, что на каждый чих это всё считывать и парсить. Как у нас обычно - на splitlines(). А это ещё и время.

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

Доверять сабжу такие эхи, как lenta.rss или lor-opennet.15 я бы не стал.

AL> Вот спорный вопрос. В идеале тогда должно быть две программы: мейлер/фетчер и тоссер, но это мне не нравится.
AL> То есть я руководствуюсь тем, что каждая программа - это вещь в себе и ничего ей для работы больше не нужно. По крайней мере стремлюсь к этому.

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

Да и вся эта возня с "вещью в себе" порой превращает исходники в макаронные изделия.

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

Баг проявился и в обычном keys.py, и в андроидовском. Так что дело в самом caesium.py, насколько понимаю.

Видимо, придётся мне всё-таки подробно почитать как описание бинарного формата sqlite, так и код реализацию aio.
Потестирую ещё потом, как будет время.

> Так напиши msgid на следующей строке, а не рядом. В чём проблема?
AL> В том, что область под всю эту информацию строко фиксирована и раздувать её нет смысла.

Но как-нибудь узнавать msgid всё равно нужно. И желательно не через 2 недели, а немного пораньше :)

AL> Почему-то у почтовиков это объеденино и никто не парится по теме. И мейлеры у FTN-сетей тоже объединяют эти действия.

Вот насчёт почтовиков неправда. Когда пишешь сообщение, всегда есть выбор: отправить сразу или сохранить.
И кнопочка "проверить почту", которая ничего никуда не отправляет без согласия.

В общем, ты уже понял, над чем работать в Цезии. И ладно.

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

Можешь и так сделать. У меня вот вообще мыслей по этому поводу нет. Как-нибудь придумаю, если что.

AL> Тут какое дело. Раньше оно чаще падало из-за длинных названий эх, например. Потому что туда ещё и msgid писался.

Так напиши msgid на следующей строке, а не рядом. В чём проблема?

AL> Не обещаю оперативного реагирования

И жаль. Это самый принципиальный вопрос. А так я тебе и в патчах могу, и на гитхабе самом, да хоть куда.

О, у меня есть идея.

Открой на станции13 файл filter.php

Замени там строку 79 на

return $this->transport->getMsgList($echo, $offset, $length);

и строку 98 на

return $this->checkHash($msgid);

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

Станции-то всё ничего, а у клиента задержка уменьшится.

На Таверне и Station13. Около 10-20 секунд на запрос.

Наверное, это из-за блэклиста. Увы, но пока Денис не почистит это дело на ii.difrex.ru, избавляться от ЧС мы не можем.

btimofeev> В исходном rss (наверное бот его парсит) в месте переноса стоит тег <br>

https://github.com/vit1-irk/ii-php/blob/master/ii-rss.php

Смотреть строки с 92 по 97. Даже я у себя на ii-net.tk в ботах немного ослабил этот фильтр.

Увы, но в идеале нужен индивидуальный подход для каждого новостного сайта. Для какой-то RSS-ки убирать ограничения, для другой - наоборот включить побольше.

Станция снова в строю!

// надо уже подыскивать какой-нибудь резерв, чтобы в случае чего быстро "переключиться"; хотя бы только для сайта проекта и документации

Обновил сертификат сегодня. И установил принудительный редирект на сабж.

Что нового:

* В настройках появился пункт "Таймаут сетевого соединения". По умолчанию равен 20 секунд. Действует не только на фетчеры, но и на всё остальное.
* Окно списка эх теперь запоминает станцию, с которой пользователь последний раз работал

А у тебя json невалидный!

Сначала было вот: https://ii-net.tk/files/andrew-nodelist.png

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

Теперь вообще ужас творится. Битые сообщения появились здесь и в пайпе.

Cмотри сюда: https://ii-net.tk/ii/difrex-fetch.php

Difrex> Пыхоскрипт больше не ругается.

Но как же это:

linux.14
fetch http://ii.difrex.ru/u/m/Uz5
pipe.2032
fetch http://ii.difrex.ru/u/m/0m/ytxo5uFCgmr0/4ipBfwZy/qS48Cmk
ii.14
fetch http://ii.difrex.ru/u/m/k4Eoo5WImUb9F/N6JdahGLb/zwg6n0mi6/PpiBcXz08

Если ты откроешь эти адреса в браузере, то увидишь пустоту. К тому же, айдишники совсем даже не 20-символьные, что уже настораживает. Скрипт не руганулся (потому что пустой ответ сервера), но в базу это всё равно не попадёт.