Ещё один пуш. Улучшил квотер. Теперь вырезаются пустые строки и подпись при цитировании.

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

vit01> Зацените в новой сборке

Наконец-то обновился. Всё таки шикарный клиент.

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

vit01>> Зацените в новой сборке
AL> Наконец-то обновился. Всё таки шикарный клиент.
Клиент ваще огонь!

+++ Sent from IDEC mobile

Никак не могу понять..
Делаю так.
Настройки станций → В строке авторизации ввожу Authstr → пытаюсь что-нибудь написать → высвечивает «ошибка отправки»

Тарам тарам там
Пам!

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

В настройках станции «Таверна» я указал адрес http://club.syscall.ru и получилось отправить сообщения. Правильно сделал?

Anotheroneuser> В настройках станции «Таверна» я указал адрес http://club.syscall.ru и получилось отправить сообщения. Правильно сделал?

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

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

Anotheroneuser> В настройках станции «Таверна» я указал адрес http://club.syscall.ru и получилось отправить сообщения. Правильно сделал?

Клуб представляет собой часть сети. Если обращал внимание на заголовки сообщений, то там указывается адрес отправителя (например у меня tavern,1). Слово перед запятой - название сервера. Не очень очевидно в современных реалиях, но в итоге даёт массу преимуществ.

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

Это просто я -- олень. Не разобрался, что там есть возможность добавлять станции.
Мне показалось, что их можно только удалять. Хотел было смириться, но что-то заставило рыть дальше )) Теперь всё на местах: клуб -- клуб, а таверна -- ... а её я удалил случайно.

> Клуб представляет собой часть сети

> часть

> сети

Он, как бы, тоже сервер?

Anotheroneuser> Это просто я -- олень. Не разобрался, что там есть возможность добавлять станции.

Ну оно не очень очевидно даже тем, кто понимает как работает IDEC. Я тоже не с первого раза разобрался =)

Anotheroneuser> Мне показалось, что их можно только удалять. Хотел было смириться, но что-то заставило рыть дальше )) Теперь всё на местах: клуб -- клуб, а таверна -- ... а её я удалил случайно.

Да и не нужна тебе таверна. Одного сервера для пользователя достаточно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Очень простой. У меня в черновиках по несколько дней лежат недописанные сообщения. Ты можешь потихоньку писать длинную статью или заметку, но при этом спокойно продолжать переписываться с людьми в том же ii://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 с его стороны) был запрос по времени. Типа, дай всё что было после такого-то времени. И это лучше, конечно. Но так уж получилось.