>>  Клуб представляет собой часть сети
>>  часть
>>  сети
Anotheroneuser> Он, как бы, тоже сервер?

Конечно. Сервера объеденены в одну сеть с общей базой сообщений. Есть клуб у Петра, таверна у меня, станция мира у Виктора. Это из тех, где пользователи есть.

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

Повышаем удобство! В новой сборке клиента теперь правильно работает сортировка

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

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

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

+++ Отправлено через IDEC Mobile
+++ Linux rulez, Windows sucks, friendship is magic

И это ура! Спасибо за обновку.

+++ IDEC-Mobile
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

А вот ещё. Какой функциональный смысл в разделении прцессов отправки и получения сообщений? Почему бы не объединить эти функции в одну кнопку? =)

+++ IDEC-Mobile
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

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

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

+++ IDEC-Mobile
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

AL> Какой функциональный смысл в разделении прцессов отправки и получения сообщений? Почему бы не объединить эти функции в одну кнопку? =)

Очень простой. У меня в черновиках по несколько дней лежат недописанные сообщения. Ты можешь потихоньку писать длинную статью или заметку, но при этом спокойно продолжать переписываться с людьми в том же pipe.2032 здесь и сейчас.

Если получение и отправку объединить в одну сущность, то ты не сможешь прочитать, например, обновления из lor-opennet, не завершив свои недописанные письма, которые должны уйти в std.club.

Черновики IDEC Mobile - это абсолютно то же самое, что черновики в Email.

# Сам клиент, в общем-то, создавался под впечатлением от стандартного Email-клиента в андроиде. Можете сравнить :)

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

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

А он вообще даёт почитать потом эху или бесконечно висит?

AL> Точное значение не скажу, но при размере индекса около 10000 сообщений поведение воспроизводится.

У меня на смартфоне никогда не было больше 2000 сообщений на эху, потому что регулярно их чищу. Надо будет подумать над тем.

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

vit01> Если получение и отправку объединить в одну сущность, то ты не сможешь прочитать, например, обновления из lor-opennet, не завершив свои недописанные письма, которые должны уйти в std.club.

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

vit01> # Сам клиент, в общем-то, создавался под впечатлением от стандартного Email-клиента в андроиде. Можете сравнить :)

Сравнивал да =)

А сейчас перешёл на K9, но это оффтопик.

Кстати, в рамках изучения java и javafx заметил, что рождается новый десктопный клиент. Может, Сергею Чумакову будет интересно. Правда не уверен, что он сюда подписан, но для анонса пока слишком рано =)

+++ IDEC-Mobile
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

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

vit01> А он вообще даёт почитать потом эху или бесконечно висит?

Висит пока не перезапустишь, но я больше пяти минут не пробовал ждать. 8000 жуёт бодро.

AL>> Точное значение не скажу, но при размере индекса около 10000 сообщений поведение воспроизводится.

vit01> У меня на смартфоне никогда не было больше 2000 сообщений на эху, потому что регулярно их чищу. Надо будет подумать над тем.

Ну у меня есть дурная привычка держать локально полную базу с узла =)

+++ IDEC-Mobile
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

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

В целом такое разделение излишне. Если при отправке ошибка - значит идёт в черновики.

AL> А сейчас перешёл на K9, но это оффтопик.

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

AL> Кстати, в рамках изучения java и javafx заметил, что рождается новый десктопный клиент.

Бери исходники у меня. Особенно части с IIMessage и с SQLite движком + парсеры внутри SimpleFunctions
Незачем зря велосипеды плодить

А так я бы запилил десктопную версию IDEC Mobile, но руки дойдут ещё нескоро. Пока всё ещё сижу на CutieFeed

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

AL>> Понял. Я что-то не подумал и опять меряю по цезию, где черновики и исходящие разделены. Для мобильного клиента, пожалуй, такое разделение излишне.
vit01> В целом такое разделение излишне. Если при отправке ошибка - значит идёт в черновики.

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

AL>> Кстати, в рамках изучения java и javafx заметил, что рождается новый десктопный клиент.
vit01> Бери исходники у меня. Особенно части с IIMessage и с SQLite движком + парсеры внутри SimpleFunctions

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

vit01> Незачем зря велосипеды плодить

Как это незачем? Велосипедостроительство наше всё!

vit01> А так я бы запилил десктопную версию IDEC Mobile, но руки дойдут ещё нескоро. Пока всё ещё сижу на CutieFeed

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

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

Хотел посмотреть фото или загрузить книжку — не получилось. Может, по-другому загружать как-то надо? Я просто нажимал «скачать»

+++ А вы пощупайте-пощупайте! В нашем деле главное — пощупать.

> Хотел посмотреть фото или загрузить книжку — не получилось. Может, по-другому загружать как-то надо? Я просто нажимал «скачать»

Насколько я помню, в клубе нет файлэх. Но лучше это уточнить у Петра.

AL> Насколько я помню, в клубе нет файлэх. Но лучше это уточнить у Петра.

Совершенно верно. :)

AL> Насколько я помню, в клубе нет файлэх. Но лучше это уточнить у Петра.

То есть, надо подключиться к другой станции?

+++ А вы пощупайте-пощупайте! В нашем деле главное — пощупать.

Anotheroneuser> То есть, надо подключиться к другой станции?

Да, к станции которая поддерживает файловые эхи.

AL>> Насколько я помню, в клубе нет файлэх. Но лучше это уточнить у Петра.
Anotheroneuser> То есть, надо подключиться к другой станции?

Ну либо так либо просить Петра пробросить фэхи =)

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

AL> Ну либо так либо просить Петра пробросить фэхи =)

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

AL>> Ну либо так либо просить Петра пробросить фэхи =)

Peter> Непроброс фэх

Да я просто хотел картинки посмотреть!))
Добавлю станцию и всё.
Самый верный путь — это когда никого не напрягать.

+++ А вы пощупайте-пощупайте! В нашем деле главное — пощупать.

Hi All!

Из документации:
"Берёт своё начало от "Клуба хороших людей" (2014) и работает на распределённом протоколе IDEC
(ii-like Data Exchange Convention), форкнутом от ii (всё от того же "Клуба")."

Что за клуб и что за ii?
Попытки найти источник не были успешными.

+++ Caesium/0.4 RC1

mirage> Что за клуб и что за ii?

Не осталось уже ни клуба хороших людей (основатель создавал какой-то там кружок любителей OpenBSD, но и тот кончился, вроде) ни, можно сказать, ii.

ii это такой обрезанный idec. Без экономии трафика и файлообмена.

mirage> Попытки найти источник не были успешными.

У меня где-то, возможно, осталась эталонная реализация ii, но не уверен. Посмотрю завтра, если не забуду.

+++ Caesium/0.4 RC1

mirage> Что за клуб и что за ii?
mirage> Попытки найти источник не были успешными.

Всё началось отсюда
https://www.linux.org.ru/news/opensource/10319264

И продолжилось здесь
https://www.linux.org.ru/news/opensource/10534550

Сейчас ii как таковой уже не существует, да и Рома (автор идеи) от нас ушёл, потому что во всём разочаровался и потерял интерес к проекту.

IDEC - это прямой потомок как самой идеи ii, так и его протокола.

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

| Esc - выход из режима чтения в режим выбора эхоконференции

Зачем выбран Esc для этой функции? Он в ncurses тормозит.

| F10 - выход из клиента

Лучше не использовать функциональные клавиши. F10 например у меня - меню терминала.


+++ Caesium/0.4 RC1

Читаю про сабж и не понимаю.

| GET /x/с/<параметры>
| Предназначен для отслеживания изменений в эхе и для отсеивания лишнего трафика. Обычное целое число.

Если из эхи можно удалять сообщения, а как я понимаю это планируется, то изменения этим методом обнаружить можно не всегда.


| /u/m/msgid/msgid/msgid

Количество msgid лимитировано длиной GET запроса на сервере.
Почему вместо этого не передавать msgid в POST?

+++ Caesium/0.4 RC1

mirage> Количество msgid лимитировано длиной GET запроса на сервере.
mirage> Почему вместо этого не передавать msgid в POST?

Думаю, из соображений простоты. А фетчеры обычно забирают сообщения пачками, скажем, по 16 сообщений. В цикле. Поэтому ограничение не критично.

mirage> | GET /x/с/<параметры>
mirage> | Предназначен для отслеживания изменений в эхе и для отсеивания лишнего трафика. Обычное целое число.

mirage> Если из эхи можно удалять сообщения, а как я понимаю это планируется, то изменения этим методом обнаружить можно не всегда.

Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.

// удалять сообщения может только держатель ноды, и это в будущем так и останется

mirage> | /u/m/msgid/msgid/msgid
mirage> Количество msgid лимитировано длиной GET запроса на сервере.
mirage> Почему вместо этого не передавать msgid в POST?

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

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

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

mirage>> | GET /x/с/<параметры>
mirage>> | Предназначен для отслеживания изменений в эхе и для отсеивания лишнего трафика. Обычное целое число.
mirage>> Если из эхи можно удалять сообщения, а как я понимаю это планируется, то изменения этим методом обнаружить можно не всегда.
vit01> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.

Тогда это уже не количество сообщений будет, а что-то другое.

vit01> // удалять сообщения может только держатель ноды, и это в будущем так и останется
mirage>> | /u/m/msgid/msgid/msgid
mirage>> Количество msgid лимитировано длиной GET запроса на сервере.
mirage>> Почему вместо этого не передавать msgid в POST?
vit01> С точки зрения масштабируемости протокола это хорошая идея, но на практике ещё никому не пригождалось скачивать сообщения очень большими порциями.
vit01> Скорее всего, Рома просто забыл про такой вариант, а после него об этом никто не задумывался.

Ну я сейчас запустил iitxt и он неслолько минут запросы слал по несколько сообщений, а мог бы и быстрее отработать.


+++ Caesium/0.4 RC1

Сабж как? В документации нет.
В коде нашел fecho, но без авторизации похоже не работает. Хотя вручную API без авторизации все отдает.

+++ Caesium/0.4 RC1

mirage> | Esc - выход из режима чтения в режим выбора эхоконференции
mirage> Зачем выбран Esc для этой функции? Он в ncurses тормозит.
mirage> | F10 - выход из клиента
mirage> Лучше не использовать функциональные клавиши. F10 например у меня - меню терминала.

Ты всегда можешь поправить биндинги в keys.py.

+++ Caesium/0.4 RC1

mirage>>> | GET /x/с/<параметры>
mirage>>> | Предназначен для отслеживания изменений в эхе и для отсеивания лишнего трафика. Обычное целое число.
mirage>>> Если из эхи можно удалять сообщения, а как я понимаю это планируется, то изменения этим методом обнаружить можно не всегда.
vit01>> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.
mirage> Тогда это уже не количество сообщений будет, а что-то другое.

На основе этого x/c мои фетчеры (caesium и iing) определяют оптимальную длину запросов к узлу для экономии трафика. Если ты приведёшь пример как эту информацию получать из хешей, то можно будет подумать.

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

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

mirage> Ну я сейчас запустил iitxt и он неслолько минут запросы слал по несколько сообщений, а мог бы и быстрее отработать.

iitxt это ii-клиент, что следует из названия. Даже если POST u/m будет в IDEC добавлен, в iitxt никто не будет ничего менять =)

+++ Caesium/0.4 RC1

mirage> Сабж как? В документации нет.

Добавь в конфиг что-то типа

fecho pictures

и всё.

mirage> В коде нашел fecho, но без авторизации похоже не работает. Хотя вручную API без авторизации все отдает.

Это баг в цезии, который я всё никак не поправлю. Просто времени сейчас нет особо. Попробуй вбить произвольную строку авторизации в конфиг и получить файлы.

+++ Caesium/0.4 RC1

mirage>> В коде нашел fecho, но без авторизации похоже не работает. Хотя вручную API без авторизации все отдает.
AL> Это баг в цезии, который я всё никак не поправлю. Просто времени сейчас нет особо. Попробуй вбить произвольную строку авторизации в конфиг и получить файлы.

Пробовал. Не фетчит.

+++ Caesium/0.4 RC1

mirage>>>> | GET /x/с/<параметры>
mirage>>>> | Предназначен для отслеживания изменений в эхе и для отсеивания лишнего трафика. Обычное целое число.
mirage>>>> Если из эхи можно удалять сообщения, а как я понимаю это планируется, то изменения этим методом обнаружить можно не всегда.
vit01>>> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.
mirage>> Тогда это уже не количество сообщений будет, а что-то другое.
AL> На основе этого x/c мои фетчеры (caesium и iing) определяют оптимальную длину запросов к узлу для экономии трафика. Если ты приведёшь пример как эту информацию получать из хешей, то можно будет подумать.

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

Другой вариант при запросе методом инкрементного листинга нода может записывать в файл эхи метку вида ">node_name"
и при следующем запросе отдавать список от этой метки и двигать ее в конец.

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

+++ Caesium/0.4 RC1

Фехи не поддерживаются этой нодой (syscall) :)

Peter> Фехи не поддерживаются этой нодой (syscall) :)

Я знаю, поэтому пытаюсь качать с http://idec.spline-online.tk/

+++ Caesium/0.4 RC1

AL>> На основе этого x/c мои фетчеры (caesium и iing) определяют оптимальную длину запросов к узлу для экономии трафика. Если ты приведёшь пример как эту информацию получать из хешей, то можно будет подумать.

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

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

+++ IDEC-Mobile
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

AL>>> На основе этого x/c мои фетчеры (caesium и iing) определяют оптимальную длину запросов к узлу для экономии трафика. Если ты приведёшь пример как эту информацию получать из хешей, то можно будет подумать.
mirage>> Эха содержит список id сообщений. Если новые id добавляются только в конец,
mirage>> то фетчер может хранить id последнего полученного сообщения и запрашивать от него.
mirage>> Только возникнет проблема если это сообщение будет удалено.
AL> А если между запросами пришло не одно сообщение, а несколько десятков? Снова тянуть весь индекс, который может весить мегабайты? Так я точно знаю насколько изменилась длина индекса с прошлой сессии и могу скачать соответствующий слайс индекса.

Несколько десятков ID и получит. Только новое.

Вот есть на ноде в эхе сообщения: ID1 ID2 ID3.
Фетчер качает их и запоминает что последнее скачаное для этой ноды-эхи - ID3.
На ноду еще приходят сообщения: ID4 ID5 ID6.
В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
И получает ID4 ID5 ID6 и запоминает ID6.
Весь индекс тянуть заново не надо.

+++ Caesium/0.4 RC1

AL>>>> На основе этого x/c мои фетчеры (caesium и iing) определяют оптимальную длину запросов к узлу для экономии трафика. Если ты приведёшь пример как эту информацию получать из хешей, то можно будет подумать.
mirage>>> Эха содержит список id сообщений. Если новые id добавляются только в конец,
mirage>>> то фетчер может хранить id последнего полученного сообщения и запрашивать от него.
mirage>>> Только возникнет проблема если это сообщение будет удалено.
AL>> А если между запросами пришло не одно сообщение, а несколько десятков? Снова тянуть весь индекс, который может весить мегабайты? Так я точно знаю насколько изменилась длина индекса с прошлой сессии и могу скачать соответствующий слайс индекса.
mirage> Несколько десятков ID и получит. Только новое.
mirage> Вот есть на ноде в эхе сообщения: ID1 ID2 ID3.
mirage> Фетчер качает их и запоминает что последнее скачаное для этой ноды-эхи - ID3.
mirage> На ноду еще приходят сообщения: ID4 ID5 ID6.
mirage> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
mirage> И получает ID4 ID5 ID6 и запоминает ID6.
mirage> Весь индекс тянуть заново не надо.

Ну и можно тоже тянуть слайсами. Просить N ids от последнего id. Последний запомнить и опять N от последнего.

+++ Caesium/0.4 RC1

> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.

Согласен. У Ромы в его gk11 (было такое развитие ii с его стороны) был запрос по времени. Типа, дай всё что было после такого-то времени. И это лучше, конечно. Но так уж получилось.

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

Каким образом фетчер узнает по одному ID сколько ему сообщений зпрашивать в слайсе? Вот он запомнил, что поледним получил сообщение mzu2V8Iz3VIAVeDg0TOi. Как он узнает сколько именно тянуть?

mirage> Вот есть на ноде в эхе сообщения: ID1 ID2 ID3.
mirage> Фетчер качает их и запоминает что последнее скачаное для этой ноды-эхи - ID3.
mirage> На ноду еще приходят сообщения: ID4 ID5 ID6.
mirage> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
mirage> И получает ID4 ID5 ID6 и запоминает ID6.
mirage> Весь индекс тянуть заново не надо.

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

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

mirage> Ну и можно тоже тянуть слайсами. Просить N ids от последнего id. Последний запомнить и опять N от последнего.

Как ты это видишь в текущем варианте? Как из ID получить что-то типа -10:10?

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

>> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
Peter> Согласен. У Ромы в его gk11 (было такое развитие ii с его стороны) был запрос по времени. Типа, дай всё что было после такого-то времени. И это лучше, конечно. Но так уж получилось.

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

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

Peter>> Фехи не поддерживаются этой нодой (syscall) :)
mirage> Я знаю, поэтому пытаюсь качать с http://idec.spline-online.tk/

Кажется я доменом ошибся. В одной доке .tk в другой .ml
В итоге в клиенте одно, в браузере другое :)

+++ Caesium/0.4 RC1

AL>>> А если между запросами пришло не одно сообщение, а несколько десятков? Снова тянуть весь индекс, который может весить мегабайты? Так я точно знаю насколько изменилась длина индекса с прошлой сессии и могу скачать соответствующий слайс индекса.
mirage>> Несколько десятков ID и получит. Только новое.
AL> Каким образом фетчер узнает по одному ID сколько ему сообщений зпрашивать в слайсе? Вот он запомнил, что поледним получил сообщение mzu2V8Iz3VIAVeDg0TOi. Как он узнает сколько именно тянуть?

Фетчер знает сколько ему надо максимум запросить чтобы не подавиться, по каким-либо причинам.
Допустим это 100 idшников.
Он запрашивает 100 записей от последнего id. В итоге будет 2 случая:
1. Придет меньше 100 id - запоминаем последний, конец.
2. Придет 100 id - запоминаем последний и запрашиваем снова 100 от него.

mirage>> Вот есть на ноде в эхе сообщения: ID1 ID2 ID3.
mirage>> Фетчер качает их и запоминает что последнее скачаное для этой ноды-эхи - ID3.
mirage>> На ноду еще приходят сообщения: ID4 ID5 ID6.
mirage>> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
mirage>> И получает ID4 ID5 ID6 и запоминает ID6.
mirage>> Весь индекс тянуть заново не надо.
AL> Это будет уже совсем другой набор договорённостей. Можно придумать что угодно, но есть такая вещь, как совместимость. В любом случае, преимуществ такого подхода пока не видно. Куда нужнее личная переписка КМК.

Это было предложение на вопрос в дискуссии о не совсем ясном числе в ответе API. Ну и это может быть расширением.

+++ Caesium/0.4 RC1

>>> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
Peter>> Согласен. У Ромы в его gk11 (было такое развитие ii с его стороны) был запрос по времени. Типа, дай всё что было после такого-то времени. И это лучше, конечно. Но так уж получилось.
AL> Тоже кривое решение как мне видится. Если порыться в архивах, то можно найти конкретные примеры потерь сообщений.

Тут много вопросов о том кто какое время берет и с каким сравнивает, как влияет на это разница во времени на нодах
и время обработки запроса. С ID проще, строже.

+++ Caesium/0.4 RC1

AL> Это будет уже совсем другой набор договорённостей. Можно придумать что угодно, но есть такая вещь, как совместимость. В любом случае, преимуществ такого подхода пока не видно. Куда нужнее личная переписка КМК.

По нетмайлу готов proposal. Просто чтобы внимание не распылять по одной теме пишу :)

+++ Caesium/0.4 RC1

mirage> Фетчер знает сколько ему надо максимум запросить чтобы не подавиться, по каким-либо причинам.

Сколько угодно =)

mirage> Допустим это 100 idшников.
mirage> Он запрашивает 100 записей от последнего id. В итоге будет 2 случая:
mirage> 1. Придет меньше 100 id - запоминаем последний, конец.
mirage> 2. Придет 100 id - запоминаем последний и запрашиваем снова 100 от него.

Этот вариант мы тоже рассматривали. Но пока думали как это сделать так, чтобы не плодить сущностей и не сломать совместимость с ii (ты до сих пор можешь взять ii-client-03 и пользоваться им), соорудили эту штуку на том, что было. Получилось просто и без излишеств.

AL>> Это будет уже совсем другой набор договорённостей. Можно придумать что угодно, но есть такая вещь, как совместимость. В любом случае, преимуществ такого подхода пока не видно. Куда нужнее личная переписка КМК.
mirage> Это было предложение на вопрос в дискуссии о не совсем ясном числе в ответе API. Ну и это может быть расширением.

Я понимаю, что предложение, но не понимаю в чём будет выигрыш? Можно и аутбаунды сделать а-ля FTN, но пользы нет.

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

AL>> Тоже кривое решение как мне видится. Если порыться в архивах, то можно найти конкретные примеры потерь сообщений.
mirage> Тут много вопросов о том кто какое время берет и с каким сравнивает, как влияет на это разница во времени на нодах и время обработки запроса. С ID проще, строже.

Ещё проще так, как есть. Потому что оно уже есть и оно простое.

Берём x/c по конференциям в подписке, сраниваем со старыми значениями с прошлой сессии, считаем максимальную разницу и одним запросом забираем индекс одним запросом. То есть два запроса на определение индекса при любом объёме новых сообщений.

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

Peter>>> Фехи не поддерживаются этой нодой (syscall) :)
mirage>> Я знаю, поэтому пытаюсь качать с http://idec.spline-online.tk/
mirage> Кажется я доменом ошибся. В одной доке .tk в другой .ml
mirage> В итоге в клиенте одно, в браузере другое :)

Да. tk я проморгал =(

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

AL>>> Тоже кривое решение как мне видится. Если порыться в архивах, то можно найти конкретные примеры потерь сообщений.
mirage>> Тут много вопросов о том кто какое время берет и с каким сравнивает, как влияет на это разница во времени на нодах и время обработки запроса. С ID проще, строже.
AL> Ещё проще так, как есть. Потому что оно уже есть и оно простое.
AL> Берём x/c по конференциям в подписке, сраниваем со старыми значениями с прошлой сессии, считаем максимальную разницу и одним запросом забираем индекс одним запросом. То есть два запроса на определение индекса при любом объёме новых сообщений.

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

+++ Caesium/0.4 RC1

AL>>> Тоже кривое решение как мне видится. Если порыться в архивах, то можно найти конкретные примеры потерь сообщений.
mirage>> Тут много вопросов о том кто какое время берет и с каким сравнивает, как влияет на это разница во времени на нодах и время обработки запроса. С ID проще, строже.
AL> Ещё проще так, как есть. Потому что оно уже есть и оно простое.
AL> Берём x/c по конференциям в подписке, сраниваем со старыми значениями с прошлой сессии, считаем максимальную разницу и одним запросом забираем индекс одним запросом. То есть два запроса на определение индекса при любом объёме новых сообщений.

Этот x/c нужен же для u/e?
Смотрю в описание u/e: смещение указывается одно для всех эх в запросе?
Получается не оптимально. Ведь в разных эхах разное количество апдейтов.
А вот например эхаA:idA/эхаB:idB/.... будет оптимальнее.

+++ Caesium/0.4 RC1

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

Можешь предложить красивое решение?

Вот, например, я подписан на несколько эх. Тогда я просто отправляю запрос x/c/bash.rss/pipe.2032/idec.talks и потом делаю u/e/bash.rss/pipe.2032/idec.talks/-50:50. Передавать что-то типа x/e/bash.rss/<id1>/pipe.2032/<id2>/idec.talks/<id3>?

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

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

mirage> Этот x/c нужен же для u/e?

Нет.

mirage> Смотрю в описание u/e: смещение указывается одно для всех эх в запросе?
mirage> Получается не оптимально. Ведь в разных эхах разное количество апдейтов.

Да, но зато никакой дополнительной нагрузки на ноду.

mirage> А вот например эхаA:idA/эхаB:idB/.... будет оптимальнее.

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

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

Сабж.

+++ Caesium/0.4 RC1

> Кто какой софт для ноды использует?

Я на https://github.com/gl00my/iing
Это запатченный на мои нужды iing.

mirage> Сабж.

В данный момент это iing, но в планах переход на новый софт, который у меня подвис в процессе и будет релизнут, видимо, уже только в следующем году. Он готов, но ещё не доделан вебинтерфейс. На этот раз на golang =)

+++ Caesium/0.4 RC1

Андрей пользует собственный iing
Пётр - патченный iing
У меня своя нода ii-php
У Дениса своя реализация на базе elasticsearch

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

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

vit01>> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.

mirage> Тогда это уже не количество сообщений будет, а что-то другое.

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

mirage> Ну я сейчас запустил iitxt и он неслолько минут запросы слал по несколько сообщений, а мог бы и быстрее отработать.

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

iitxt медленный, потому что он хитро парсит сообщения и что-то пересчитывает, это к автору клиента вопрос.

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

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

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

vit01>>> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.
mirage>> Тогда это уже не количество сообщений будет, а что-то другое.
vit01> Надо поправить в документации, чтобы не заводить путаницу. Но в первом приближении это обычно и есть количество сообщений. Можно timestamp новейшего сообщения в эхе подставлять, наши клиенты этот вариант съедят даже без переписывания кода.

Ваши съедят, а мои подавятся. На базе x/c мои фетчеры вычисляют размер слайса.

mirage>> Ну я сейчас запустил iitxt и он неслолько минут запросы слал по несколько сообщений, а мог бы и быстрее отработать.
vit01> Дефолт для клиентов - скачивать по 20 сообщений за раз (можно увеличить в настройках), а индекс получать пачками.
vit01> iitxt медленный, потому что он хитро парсит сообщения и что-то пересчитывает, это к автору клиента вопрос.
mirage>> Эха содержит список id сообщений. Если новые id добавляются только в конец,
mirage>> то фетчер может хранить id последнего полученного сообщения и запрашивать от него.
mirage>> Только возникнет проблема если это сообщение будет удалено.
vit01> Проблема не только в удалении, но и в том, что сообщения могут не сохранять порядок в индексе базы. То есть они могут быть перепутаны хронологически.

Да все эти варианты мы уже рассматривали и обсуждали. Начиная с лета 2014 и заканчивая обсуждением расширенной u/e. Пройденный этап, откинутые варианты. Нет смысла к ним возвращаться. К тому же до сих пор не было озвучено предполагаемых преимуществ перед текущим вариантом.

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

vit01>>>> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.

vit01>> Надо поправить в документации, чтобы не заводить путаницу. Но в первом приближении это обычно и есть количество сообщений. Можно timestamp новейшего сообщения в эхе подставлять, наши клиенты этот вариант съедят даже без переписывания кода.

AL> Ваши съедят, а мои подавятся. На базе x/c мои фетчеры вычисляют размер слайса.

Действительно, тут я ошибся. IDEC Mobile тоже подсчитывает слайсы по ним (хоть и более хитро), а ещё уведомления выдаёт :)

Важно, что поле только возрастает, и что на сервере после удаления сообщений значение /x/c не должно уменьшаться.

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

Возможно вчера успел утечь в фэху music сабж. bitjam_021 без расширения. Просьба сисопов проверить свои узлы в случае подписки на эту фэху.

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

AL> Возможно вчера успел утечь в фэху music сабж. bitjam_021 без расширения. Просьба сисопов проверить свои узлы в случае подписки на эту фэху.

Сначала удалил файл зиповник, а потом только увидел, что "без расширения". Скачал обратно :)

Ты предупреждай, когда большие файлы кидаешь. У меня на фетчере лимит то 30 мегабайт, то 35 на файл.

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

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

AL>> Возможно вчера успел утечь в фэху music сабж. bitjam_021 без расширения. Просьба сисопов проверить свои узлы в случае подписки на эту фэху.
vit01> Сначала удалил файл зиповник, а потом только увидел, что "без расширения". Скачал обратно :)
vit01> Ты предупреждай, когда большие файлы кидаешь. У меня на фетчере лимит то 30 мегабайт, то 35 на файл.
vit01> Поэтому, чтобы *все* твои файлы "доходили до адресата", мне приходится править конфиг, увеличивая лимит, потом вручную дёрнуть фетчер и править конфиг обратно.

Ну я ж не знал, что лимит такой небольшой. Я файлы меньше 100 Мб кидаю. Зато почти каждый день =)

Ладно. Буду в музыкальные эхи анонсить.

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

AL> Ну я ж не знал, что лимит такой небольшой. Я файлы меньше 100 Мб кидаю. Зато почти каждый день =)
AL> Ладно. Буду в музыкальные эхи анонсить.

Увеличил до 80 мб лимит. Пока место на диске позволяет.

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

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

AL>> Ну я ж не знал, что лимит такой небольшой. Я файлы меньше 100 Мб кидаю. Зато почти каждый день =)
AL>> Ладно. Буду в музыкальные эхи анонсить.
vit01> Увеличил до 80 мб лимит. Пока место на диске позволяет.
vit01> Но файлы по-хорошему анонсировать всё равно надо. Во-первых, не все следят за файлэхами. Во-вторых, чтобы не скачивать котов в мешке, ведь иногда описания может быть недостаточно.

Ну вообще, bitjam podcast он и есть bitjam podcast =)

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

Difrex> // А я на динамик новый дизайн завез. Думаю допилить его(постинг) наконец-то и выложить сорцы

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

Хотелось посмотреть поток сообщений в "роботизированных" эхах по дням недели в среднем за месяц, а там только для "человеческих"

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

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

vit01> Как раз заходил туда сегодня, чтобы глянуть статистику по эхам. Правда, чего нужно, не нашёл
vit01> Хотелось посмотреть поток сообщений в "роботизированных" эхах по дням недели в среднем за месяц, а там только для "человеческих"
Вот этого через АПИ не получишь - наружу не торчит, т.к. для статов по дням недели используется groovy,
а это потенциальная уязвимость.

vit01> Можешь пожалуйста сделать похожую страничку со статистикой для новостных эх? Ну или хотя бы подсказку дать насчёт API Elasticsearch, чтобы вытащить данные.
Сделаю страничку для роботов :)
Еще есть в планах доливать раз в неделю данные в read-only индекс и прямо вставлять iframe из кибаны,
чтобы все интерактивно было.

vit01> +++ Отправлено через IDEC Mobile
vit01> +++ GNU/Linux, Android, physics, MLP:FIM

+++ Емакс не пищит и текст не портит

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

Нельзя ли мне какую-нибудь схему.. или ссылку на объяснение-для-лиц-далёких-от?
А ещё лучше -- просто подсказку, как запоминать адреса конкретных сообщений.

> А ещё лучше -- просто подсказку, как запоминать адреса конкретных сообщений.

Я бы тоже хотел такую штуку, но сейчас она на syscall только для админа. Это те самые избранные сообщения.
В Android клиенте, наверное, есть.
А так - нажать на "глаз" над сообщением и скопировать куда то себе в редактор. :)

> нажать на "глаз" над сообщением и скопировать

О, нормально. Вполне подойдёт.
То есть, каждое сообщение здесь имеет собственный адрес, который никогда не поменяется?

Anotheroneuser> О, нормально. Вполне подойдёт.
Anotheroneuser> То есть, каждое сообщение здесь имеет собственный адрес, который никогда не поменяется?

Совершенно точно. Более того, это сообщение можно на любой ноде найти по этому хешу.

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

Anotheroneuser> А ещё лучше -- просто подсказку, как запоминать адреса конкретных сообщений.

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

В CutieFeed есть аналогичная звёздочка.

Если сообщение в избранных больше не нужно (например, ты ответил уже на него), то убираешь звёздочку.

2. Если нужна ссылка на сообщение, то тебе нужен его уникальный ID, состоящий из 20 символов.

В IDEC Mobile он находится снизу темы сообщения, прямо под отправителем и получателем. Отображается как "msgid: blablabla"

Достаточно просто коротко тапнуть на надпись "msgid", и этот айдишник скопируется в буфер обмена.

В CutieFeed msgid тоже отображается, его можно выделить и скопировать.

3. Для IDEC Mobile есть и третий вариант. Наверху справа в верхней панели есть кнопка с тремя точками, где меню. В меню есть пункт "сохранить в файл".
Сообщение вместе с айдишником сохраняется в текстовый файл. Тоже полезно.
Также в этой менюшке есть пункт "поделиться", который делает похожую вещь. msgid в тексте сообщения тоже сохраняется

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

Ого. Благодарю тебя.
О CutieFeed мне до сих пор слышать не приходилось, кстати.

Anotheroneuser> О CutieFeed мне до сих пор слышать не приходилось, кстати.

https://github.com/idec-net/cutiefeed

Вдруг пригодится

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

Пригодится, наверняка. Только разберусь, как его запускать..

vit01> 2. Если нужна ссылка на сообщение, то тебе нужен его уникальный ID, состоящий из 20 символов.

vit01> Достаточно просто коротко тапнуть на надпись "msgid", и этот айдишник скопируется в буфер обмена.

Кстати, а как потом найти по этому id сообщение (в мобильном клиенте)? Если вбиваю в поиск, то не находит. И если сообщения нет в базе, то клиент показывает, что его нет: было бы замечательно, что бы он его предлагал скачать или сразу скачивал.

vit01>> Достаточно просто коротко тапнуть на надпись "msgid", и этот айдишник скопируется в буфер обмена.

btimofeev> Кстати, а как потом найти по этому id сообщение (в мобильном клиенте)? Если вбиваю в поиск, то не находит. И если сообщения нет в базе, то клиент показывает, что его нет: было бы замечательно, что бы он его предлагал скачать или сразу скачивал.

Достаточно лишь перейти по ii-ссылке вида 2GfFXMiDX4GNqmn01BjK из браузера или из любого другого приложения

А если сообщения нет в базе, то Меню -> "Обновить с сервера"

Предлагать скачивать - это неплохая идея, надо будет реализовать

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

Anotheroneuser> Нельзя ли мне какую-нибудь схему.. или ссылку на объяснение-для-лиц-далёких-от?
Anotheroneuser> А ещё лучше -- просто подсказку, как запоминать адреса конкретных сообщений.
Не знаю будет ли тебе удобно, но на https://dynamic.lessmore.pw есть избранное.
Щелкаешь на зведочку в правом нижнем углу сообщения и оно добавляется в твое избранное,
потом увидеть можно тут: https://dynamic.lessmore.pw/favorites

// Починил ноду(IDEC API) на динамике. Работают схемы x/c, list.txt, m, e, u/m, u/e

+++ Емакс не пищит и текст не портит

vit01> Достаточно лишь перейти по ii-ссылке вида 2GfFXMiDX4GNqmn01BjK из браузера или из любого другого приложения

Неплохо, если бы клиент умел искать сообщения по id. А то по тексту умеет, а id игнорирует.

Сабж. А именно эху ii.test.14. Я начинаю тестирование писанины, как через веб, так и через клиент :)

+++ картошки хватит на всех

Загейтовано.

2All: проверьте в pipe.2032 сообщения 2QzNqUiyuoPcPn0l74KP и 0dIDXSJTLtR8N2KnLTl1 , они порченные, без текста

> Пригодится, наверняка. Только разберусь, как его запускать..

На Арче из зависимостей только python, bash и python-pyqt5

На Дебиане/Убунте список зависимостей такой: python3-pyqt5, python3-pyqt5.qtsvg

Запускать сам клиент очень просто: файлик cutiefeed.py
Либо пометить для исполнения, либо набрать python3 cutiefeed.py

Тээкс.. Сейчас попробую..

> Загейтуйте

Как это по-русски?)) «Закрыть ворота»?

+++ А вы пощупайте-пощупайте! В нашем деле главное — пощупать.

А это норм, что IDEC Mobile в качесте нового сообщения формирует такой вот текст?

ii.test.14
All
another test
Test

Т.е. всего 3 строки в заголовке, хотя в стандарте у нас вот что:

1	echoarea	эхоконференция, в которую помещается сообщение
2	msgto	    пользователь, которому вы пишете (либо All, если обращаетесь ко всем)
3	subj	    тема сообщения
4	-	        пустая строка
5	repto	    если начинается с @Repto:, то нода проставляет тэг repto (указывает id письма, на которое отвечаем). Иначе строка относится к тексту сообщения
6 и далее msg	текст сообщения

Difrex> А это норм, что IDEC Mobile в качесте нового сообщения формирует такой вот текст?


Такого быть не может, иначе сообщение не отправится
Я перепроверил, всё норм создаётся

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

Собственно сабж. Можно читать и писать. Протестированы все основные клиенты,

исправленны все найденные(мною) баги. Попутно добавились фичи и исправления в пакет go-idec.
Исходники ноды отзеркалены на гитхаб: https://github.com/idec-net/lessmore-node
На этой или следующей неделе появится возможность постить из веб-гуйни.

Выпью пива :)

// А еще на работе зарелизили в прод сегодня систему автоматического инцидент-менеджмента

+++ Caesium/0.4 RC1

Anotheroneuser> > Загейтуйте
Anotheroneuser> Как это по-русски?)) «Закрыть ворота»?
Зацени, что у нас есть https://ii-net.tk/idec-doc/?p=terminology :)

+++ Емакс не пищит и текст не портит

Словарище.

Загейтуйте динамик.
Сабж. А именно эху ii.test.14. Я начинаю тестирование писанины, как через веб, так и через клиент

Синхронизируйте узел "динамик".
Такая вот тема сообщения.
Синхронизировать нужно эху ii.test.14.
# Так и не понял, как перевести "эха". Получается, что сеть состоит из узлов, которые, в свою очередь, содержат ленты сообщений. А ленты содержат сообщения. А сообщения могут находиться вне лент? )) Где-нибудь в нигде.

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

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

+++ картошки хватит на всех

Да, сеть реализует распределенную базу сообщений.
Ты, например, писал со станции syscall, а я с dynamic, а теперь
эти сообщения есть на всех узлах(наверняка).

+++ Емакс не пищит и текст не портит

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

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

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

В новой сборке:

1. Менюшка поиска теперь позволяет искать сообщения по msgid
2. В фэхах можно копировать имя файла (например, для вставки в Orgzly, см. A63NgO1GzgHbJSCeyl3S )

3. Если сообщение отсутствует в базе данных (например, при открытии ii-ссылки), то клиент автоматически предложит его скачать

После обновления можете протестировать:

Пример 1, Таверна: PaE7u959rHu625taZeBy
Пример 2, Станция Мира: TasqAFIeZAD4ny2iESIK

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

Функция executeQuery вызывается довольно часто и туда педаются данные путем слияния строк, например
Строка 285 файла transports.php

$this->executeQuery("insert into `$this->tablename` values(NULL, '".$msg['id']."', ' ... '".$msg['msg']."')");

Пока не ясно можно ли использовать это без авторизации. Код валидации authstring не читал.
Но имея поинта к этому участку кода появляется доступ :).

Да, в пхп можно отключить вывод ошибок в браузер, что лучше сделать :)

// А поставьте на фетч с dynamic основные эхи. Вроде как, все работает.

Сегодня появилось немножко свободного времени, и я решил таки разобраться со станцией

> Сабж. Ругается на базульку
Это обычно бывает, когда демон mariadb подыхает. Надо глянуть логи сервера

> Функция executeQuery вызывается довольно часто и туда педаются данные путем слияния строк, например
> Строка 285 файла transports.php

Специально прошерстил исходники на предмет сырых запросов.
Конкретно здесь ложная тревога. Ты, наверное, не заметил, что перед запуском этого кусочка кода сообщение эскейпится через prepareInsert, внутри которого вшит $db->real_escape_string
В getMessages эскейпится аналогично, в getMsgList и countMessages стоит жёсткий фильтр на все параметры внутри filter.php, так что зараза не пройдёт.

Не надо уж меня совсем дремучим говнокодером считать =)
Любые, даже начинающие, PHP-шники про SQL-инъекции думают сразу на стадии проектирования, и эта проблема съедает немалую часть времени на кодинг.

> Да, в пхп можно отключить вывод ошибок в браузер, что лучше сделать :)

Я его как раз специально включил, причём поставил самый verbose-уровень, чтобы быстро можно было понять, в чём проблема, и починить. Оно даже на варнинги бросает исключение и прерывает исполнение всего кода.

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

Когда сервак в дауне, ping выдаёт ответы от какого-то zapret.hostnode.net (или .com?)

Путём гуглинга выяснилось, что проблема на стойке в Москве у webdc.ru

Хочу окончательно съехать со нашего FirstVDS к немцам на Hetzner, но переносить все запущенные сервисы пока нет времени. Немцы крутые, у них всегда чёткий аптайм без факапов, и второй сервак (а именно debug.ii-net.tk) работает как часы.

> // А поставьте на фетч с dynamic основные эхи. Вроде как, все работает.

Уже давно как всё фетчится, твои сообщения видим

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

Я там коммитнул в сабж. У меня опять проэтосамован почтовый ящик а то.

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

AL> Я там коммитнул в сабж. У меня опять проэтосамован почтовый ящик а то.

Обновлено.

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

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

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

В новой сборке клиента был пофикшен один из самых критичных багов, который давно мозолил мне глаза: приложение не запускалась на ОС версий ниже 4.4

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

+++ Sent from Android 4.2 (Emulator)