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-ссылке вида 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-ссылке вида ii://2GfFXMiDX4GNqmn01BjK из браузера или из любого другого приложения

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

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

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

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

2All: проверьте в pipe.2032 сообщения ii://2QzNqUiyuoPcPn0l74KP и ii://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.
# Так и не понял, как перевести "эха". Получается, что сеть состоит из узлов, которые, в свою очередь, содержат ленты сообщений. А ленты содержат сообщения. А сообщения могут находиться вне лент? )) Где-нибудь в нигде.

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