разговоры об ii/IDEC


\/ . doesnm to Andrew Lobanov @ Re: Полуневдимые эхи 27/10/24 10:34

shaos>>>> Меньше это Gopher или Nex овер телнет :)
revoltech>>> Да не обязательно овер телнет, но да, суть в том, чтобы не относящихся непосредственно к ii метаданных меньше гонять. Здесь и так сообщения в base64 оборачиваются, что уже 4/3 от полезной нагрузки...
doesnm>> Го дропнем base64
AL> Предлагаю отказаться от HTTP, base64, списков и переделать всё на актбаунды.

Поддерживаю

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

41Cmc2... . ОТВЕТИТЬ



\/ . hugeping to shaos @ Re: Стандарт 27/10/24 10:31

shaos> А зачем отдельно, если оно уже есть - никаких новых полей ненадо т.к. всё уже прям тут - бери и используй как говорится :)

Я там выше сообщение написал про то как можно сделать редактирование. sZbskcy7huzEVJlsSDIF

То-есть, если считаем msgid настоящим хешем, так уже не сделать.

Мне интереснее, конечно, эту проблему решить.

el4ch9... . ОТВЕТИТЬ



\/ . shaos to hugeping @ Re: Стандарт 27/10/24 10:15

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

И потом я же не предлагаю всё ломать - кто-то будет использовать msgid для проверки целостности, а кто-то нет (я вообще думаю у себя по эхам это сделать - где то показывать неправильные сообщения другим цветом или с другим фоном, а где-то просто отбрасывать как потенциально вредные).

Us1o8I... . ОТВЕТИТЬ



\/ . shaos to Andrew Lobanov @ Re: Стандарт 27/10/24 10:12

> shaos> Проблему большого траффика когда тянется всё подряд без оглядки
> Эту проблему прекрасно решают слайсы.

Ну будут решать ещё лучше, когда необходимость дёргания будет решаться не по количеству сообщений в эхе, а по хешу т.к. например в ii-php количество сообщений это реальное количество сообщений в эхе и в /list.txt, и в /x/c (т.е. оно может не только расти, но и уменьшатся, и даже оставаться неизменным когда убавилось столько же сообщений сколько и добавилось, но этого никто не заметил т.к. сравнивают номера).

> Ну и не лучше ли вынести это в отдельный ендпоинт вместо хаченья list.txt?

Обычный /list.txt останется как был, а для хешей я пока делаю на выбор:
/list.txt?h=1
/listhsh.txt
и по аналогии с /x/c будет /x/h но вместо количества сообщений там будут хеши

d1YtjJ... . ОТВЕТИТЬ





\/ . Andrew Lobanov to shaos @ Re: Стандарт 27/10/24 09:36

shaos> Проблему большого траффика когда тянется всё подряд без оглядки

Эту проблему прекрасно решают слайсы. Посмотри на трафик от Петра. Ну и не лучше ли вынести это в отдельный ендпоинт вместо хаченья list.txt?

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

LK1aBw... . ОТВЕТИТЬ



\/ . Andrew Lobanov to All @ RSS-гейт таверны 27/10/24 09:24

Починил сабж.

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

fCvpt8... . цепочка . ОТВЕТИТЬ



\/ . hugeping to shaos @ Re: Стандарт 27/10/24 09:38

shaos> тогда msgid будет решать только задачу идентификации сообщения уникальным образом и больше никакую другую

Собственно, для этого msgid и нужен. Если ты хочешь на него нагрузить что-то ещё "для красоты", то да, не будет работать редактирование, как минимум. Я понял, что у нас тут разные стремления. Но может быть лучше сделать базовую технологию обмена, а подлинность целостность - это отдельно? Без возможности редактирования сообщений мне ii-go бесполезен. Я ведь использую его для создания заметок. У меня даже резюме лежит на нём. :)

f5dWhd... . ОТВЕТИТЬ





\/ . shaos to hugeping @ Re: Стандарт 27/10/24 09:20

тогда msgid будет решать только задачу идентификации сообщения уникальным образом и больше никакую другую, а в ii/IDEC с самого начала (и до сих пор) msgid потенциально пригоден для решения аж 3 задач:
- идентификация уникального сообщения (с высокой степенью защитой от коллизий);
- проверка целостности сообщения (что сообщение не повредилось при передаче от узла где сообщение было принято к узлу где оно читается);
- проверка подлинности сообщения (что зловредные индивиддуумы не подменили источник, приёмник, время, тему ну и до кучи тело сообщения на своё при передаче).

MeQskU... . ОТВЕТИТЬ



\/ . Andrew Lobanov to revoltech @ Re: Полуневдимые эхи 27/10/24 09:10

revoltech> * длина файла с айдишниками эхи не настолько велика, чтобы заморачиваться со слайсами, а локально накладные расходы они увеличивают существенно (наверное, откачу логику tiifetch до простого выкачивания эх);

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

revoltech> * на данный момент докачанность списка айдишников можно проверять наличием \n\n в конце, но в теории можно придумать сценарий, в котором это не сработает, пусть и крайне маловероятный.

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

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

367LiU... . ОТВЕТИТЬ



\/ . Andrew Lobanov to revoltech @ Re: Полуневдимые эхи 27/10/24 09:10

ahamai>> как отличить "конец передачи" от "оборвалось", чтобы не запарсить что не то
revoltech> В том же гофере (как минимум при выдаче гофермапов) наши деды решили это гениальным способом: точкой на конце. Просто точка без ничего на отдельной строке после текста (CRLF . CRLF). Здесь в спецификации я вижу, что содержимое эхи заканчивается пустой строкой (LF LF). Но такое может возникнуть и в результате преждевременного закрытия соединения. А вот точка там не возникнет сама по себе никогда.

Почему?

j1RZrx... . ОТВЕТИТЬ



\/ . Andrew Lobanov to revoltech @ Re: xc: lor 27/10/24 09:10

ahamai>> а вообще, у нас сейчас фанаты технологии, но нет фанатов распределённости и локального хранения.
revoltech> Есть. Поэтому все подвижки в сторону «выкачивать не всё и не отовсюду» предлагаю отметать, как вредоносные.
revoltech> В идеале — дайте мне возможность скачать все эхи одним файлом, а дальше уж разберусь локально, что с этим делать.

Для этого вообще никакой протокол не нужен. Просто паковать всю станцию в бандл и сразу отдавать клиенту. Ну и что что там несколько сотен мегабайт? Зато всё и клиент сам разберётся что ему надо, а что нет.

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

579DmZ... . ОТВЕТИТЬ



\/ . Andrew Lobanov to revoltech @ Re: Полуневдимые эхи 27/10/24 09:10

shaos>> base64 нужен т.к. позволяет ii транспорту работать в том числе и по последовательным 7-битным каналам - через COM порт там или прямо в тексте е-мейлов без mime кодирования (которое также в текст по сути)
revoltech> Интересно девки пляшут. То у нас без HTTP(S) никуда, то семибитные каналы через ком. Надо бы уж определиться.

Мы и определились и отказались от максимализма.

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

lkMW5j... . ОТВЕТИТЬ



\/ . Andrew Lobanov to ahamai @ Re: xc: lor 27/10/24 09:09

ahamai> Думаю о создании станции lor2ii, которая будет медленно и печально собирать сообщения с текущих тем лора.
ahamai> Без веб интерфейса, либо с веб интерфейсом только для пойнтов.
ahamai> При этом пойнты могут комментировать эти сообщения и они будут доступны другим пойнтам. Получится этакий OverLor.
ahamai> Сообщения с лора тэгировать чем-то типо lorlink/урл-на-сообщение.
ahamai> Вернуть http-клиента и ориентировать на всё это.
ahamai> Кому-нибудь такое интересно?

А чем текущая эха не устраивает? Зачем аж отдельная станция для отдельной эхи?

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

QpzAp7... . ОТВЕТИТЬ



\/ . Andrew Lobanov to doesnm @ Re: Полуневдимые эхи 27/10/24 09:09

shaos>>> Меньше это Gopher или Nex овер телнет :)
revoltech>> Да не обязательно овер телнет, но да, суть в том, чтобы не относящихся непосредственно к ii метаданных меньше гонять. Здесь и так сообщения в base64 оборачиваются, что уже 4/3 от полезной нагрузки...
doesnm> Го дропнем base64

Предлагаю отказаться от HTTP, base64, списков и переделать всё на актбаунды.

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

t8bZVs... . ОТВЕТИТЬ



\/ . Andrew Lobanov to revoltech @ Re: Полуневдимые эхи 27/10/24 09:09

tuple>> Почему жирный-то? Почти натуральный plaintext. Куда меньше?
revoltech> Потому что статусы и заголовки, например. См. как в гофере или нексе сделано: строка запроса — ответ, всё.
revoltech> Пример запроса по Nex: echo /u/e/idec.talks | nc station.domain 1900
revoltech> Ничего, кроме нетката, телнета или подобного, в основе не требуется.
revoltech> Отвечаю заранее на вопрос «а как же постить»? Как в NPS — на другой порт:
revoltech> cat <<EOF | nc station.domain 1915
revoltech> /u/point
revoltech> [auth_string]
revoltech> [base64_message]
revoltech> .
revoltech> EOF
revoltech> Вот тут уж действительно меньше некуда.

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

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

5gdXxG... . ОТВЕТИТЬ



\/ . Andrew Lobanov to ahamai @ Re: Стандарт 27/10/24 09:09

ahamai> что с лор.опеннетом делать будем?

Чинить. Займусь сегодня.

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

Z9YlS7... . ОТВЕТИТЬ



\/ . Andrew Lobanov to revoltech @ Re: Полуневдимые эхи 27/10/24 09:09

AL>> Потому что документация описывает IDEC.
revoltech> Возникает вопрос: её здесь вообще кто-нибудь ещё читал?

И даже писал.

revoltech> Первый же абзац в https://github.com/idec-net/new-docs/blob/master/extensions.md:
>> Здесь описаны расширения протокола, являющиеся основным отличием IDEC от ii. Многие из них реализовывать совсем необязательно.
revoltech> И далее чуть ниже пункт «Список эхоконференций», описывающий GET /list.txt.

Бывает.

revoltech> То есть документация называет GET /list.txt одним из основных отличий IDEC от ii. А мне тут рассказывают, что «это было в ii». Ну так документацию тогда поправьте, если это было в ii, а не эксклюзив IDEC.

Зачем?

revoltech> Я вот вместе с кодобазой tii начал вести свой ii-doc.txt, где описываю только реализованные в tii части протокола. И с пометкой IDEC extension у меня там только GET /x/features и один из вариантов /u/e, который со слайсами.

Молодец.

AL>> Слишком много оверхеда.
revoltech> Слишком много сарказма. Если уж позиционируем протокол как альтернативу щитвебу и если уж спецификация не обязывает именно к HTTP(S)-транспорту (опять гитхаб процитировать?), то вполне логично принимать и предложения по более легковесным протоколам вместо упора в жирный HTTP(S).

Ну то, как Вы позиционируете протокол, мы узнали только что. Сидим вот, думаем что дальше с этим делать.

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

At31Fq... . ОТВЕТИТЬ



\/ . Andrew Lobanov to shaos @ Re: Стандарт 27/10/24 09:08

>> ahamai> предлагаю включить в стандарт возможность исполнения list.txt?h=1
>> Что это должно делать?
shaos> Возвращать хеши эх вместо дескрипшина:
shaos> ====
shaos> idec.talks:1699:hsh/wHerzeypz8j1d8tviSRh
shaos> blcat.local:6:hsh/kAIYYMMc5DWK0FJhsW64
shaos> retro.talks:62:hsh/bahvlLwAzK2ArGHvXWat
shaos> bot.habr.rss:157:hsh/dwqigyrvKJQURxn88dwq
shaos> lor.opennet:127:hsh/12hqQwDfGoRXxD5ILIfj
shaos> ru.humor.14:817:hsh/4GxIyw2R69G75LlwnG0r
shaos> lor.gold:47:hsh/f4BQcuDnC7LTwzQHZ42k
shaos> linux.14:919:hsh/k8AiOJGrmMm1Q30W0Stz
shaos> ====

Какую проблему это решает?

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

l2OQSH... . ОТВЕТИТЬ





\/ . hugeping to hugeping @ Re: Стандарт 27/10/24 08:08

hugeping> Да, хеш тут условный, это просто ID сообщения, не обязан совпадать при перерасчёте (он и не будет).

Да, если это прям режет глаз. То можно делать не хеш сообщения. Любой алгоритм генерации uuid. Например, хеш от времени в мс + имя системы...

P.S. Edited: 2024-10-27 08:08:47

GoiZDs... . ОТВЕТИТЬ



\/ . hugeping to Andrew Lobanov @ Re: Стандарт 27/10/24 08:02

Тут опять хаос с топиками. Я буду всегда отвечать в топике "Стандарт" для порядка. Появились такие мысли:

1) Хеши в list.txt мне не нравятся потому, что list.txt на данный момент не является обязательным и выглядит как просто информационный. Почему бы, если уж делать хеши эх, не сделать что-то вроде /u/h/ ? Использование хешей именно в list.txt да ещё и в позициях дескрипшена - выглядит как хак.

2) x/c считаю должен отражать реальный счётчик сообщений для просмотра "на лету" совместно со слайсами. Либо да, убирать и слайсы и x/c

3) Редактирование сообщений это не только "в последний момент" поменять что-то. Это вполне себе необходимая вещь, если мы рассматриваем idec не просто как болталку. Например, есть статья я её редактирую. Ссылка на статью должна быть постоянной... Для контента это важно.

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

MsgId делится на две части. 1-я - собственно ID (изначально считается как хеш) и счётчик изменений, который всегда увеличивается на 1. Гарантируется что в базе ID всегда уникальны и у нас нет двух сообщений с одинаковым ID, но разными счётчиками. При работе с сообщениями в системе мы в целом пользуемся ID, а счётчик изменений используем при фетче если нужно "обновить" отредактированное сообщение.

Ну что то вроде: IIIIIIIIIIIIIIIIrrrr. I - хеш, rrrr - закодированный номер изменений. А может и не закодированный а прямо: 1t0CZs5lzqVxsoht0001

Да, хеш тут условный, это просто ID сообщения, не обязан совпадать при перерасчёте (он и не будет).

sZbskc... . ОТВЕТИТЬ



\/ . revoltech to shaos @ Re: Полуневдимые эхи 27/10/24 07:54

shaos> а на старых "классических" эхах несходящиеся сообщения можно продолжать показывать помечая специальным символом...

Ну я у себя теперь просто делаю приписку (ID hash mismatch!) рядом с айдишником у таких сообщений.

g3Az3x... . ОТВЕТИТЬ



\/ . revoltech to shaos @ Re: Полуневдимые эхи 27/10/24 07:52

shaos> не будем забывать про слабые ретроплатформы где память 64КБ и меньше

А на такие платформы уже портировали Tcl 8.6, sqlite3 и прочее? Я же конкретно насчёт своего клиента/фетчера говорю. Там-то понятное дело, что другие подходы ко всему нужны.

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

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

rR85z7... . ОТВЕТИТЬ



\/ . shaos to revoltech @ Re: Полуневдимые эхи 27/10/24 06:28

> длина файла с айдишниками эхи не настолько велика

не будем забывать про слабые ретроплатформы где память 64КБ и меньше

например список хешей lor-openned.17 весит 299КБ и они точно не влезут в память ретрокомпьютера целиком

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

ySmtlA... . ОТВЕТИТЬ



\/ . shaos to revoltech @ Re: Полуневдимые эхи 27/10/24 05:53

> айдишник сообщения не может использоваться для проверки целостности, поскольку битые есть даже среди относительно новых (за 2024);

ну почему не может? может

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

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

kUxuXZ... . ОТВЕТИТЬ



\/ . revoltech to shaos @ Re: Полуневдимые эхи 27/10/24 05:28

В сухом остатке _на данный момент_ имеем следующее:

* айдишник сообщения не может использоваться для проверки целостности, поскольку битые есть даже среди относительно новых (за 2024);
* длина файла с айдишниками эхи не настолько велика, чтобы заморачиваться со слайсами, а локально накладные расходы они увеличивают существенно (наверное, откачу логику tiifetch до простого выкачивания эх);
* на данный момент докачанность списка айдишников можно проверять наличием \n\n в конце, но в теории можно придумать сценарий, в котором это не сработает, пусть и крайне маловероятный.

BG1YzQ... . ОТВЕТИТЬ



\/ . shaos to revoltech @ Re: Полуневдимые эхи 27/10/24 05:15

> Что есть маразм by design. Хэш — он на то и хэш

с одной стороны редактирование мессаджей это местная самодеятельность (типа ой, я тут запятую забыл поставить, дай ка побырому исправлю пока мессага не зафетчилась другими узлами) т.е. by design таки подразумевалось, что мессаги не редактируются

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

P.S. хеш с подменой двух небуквоциферных символов в хеше на A и z по идее можно и оставить как рудимент прошлого т.к. оно даёт возможность по статистическому анализу букв используемых среди N хешей со 100% уверенностью сказать, что они пришли из ii/IDEC-сетей ;)

htwiRz... . ОТВЕТИТЬ



\/ . revoltech to ahamai @ Re: Полуневдимые эхи 27/10/24 04:59

ahamai> как отличить "конец передачи" от "оборвалось", чтобы не запарсить что не то

В том же гофере (как минимум при выдаче гофермапов) наши деды решили это гениальным способом: точкой на конце. Просто точка без ничего на отдельной строке после текста (CRLF . CRLF). Здесь в спецификации я вижу, что содержимое эхи заканчивается пустой строкой (LF LF). Но такое может возникнуть и в результате преждевременного закрытия соединения. А вот точка там не возникнет сама по себе никогда.

HIp0R0... . ОТВЕТИТЬ



\/ . shaos to revoltech @ Re: Полуневдимые эхи 27/10/24 04:48



\/ . revoltech to ahamai @ Re: xc: lor 27/10/24 04:41

ahamai> а вообще, у нас сейчас фанаты технологии, но нет фанатов распределённости и локального хранения.

Есть. Поэтому все подвижки в сторону «выкачивать не всё и не отовсюду» предлагаю отметать, как вредоносные.

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

Fuvs4U... . ОТВЕТИТЬ



\/ . revoltech to shaos @ Re: Полуневдимые эхи 27/10/24 04:32

shaos> Многие узлы допускают редактирование сообщений без изменения хеша

Что есть маразм by design. Хэш — он на то и хэш, чтобы отражать изменения в содержимом, иначе на... зачем он нужен?

shaos> base64 нужен т.к. позволяет ii транспорту работать в том числе и по последовательным 7-битным каналам - через COM порт там или прямо в тексте е-мейлов без mime кодирования (которое также в текст по сути)

Интересно девки пляшут. То у нас без HTTP(S) никуда, то семибитные каналы через ком. Надо бы уж определиться.

В почте это сделано просто ради кучи легаси-софта из 1980-х, а первая версия ii появилась в 2014 году, когда весь нормальный мир давно перешёл на UTF-8. Для реальных семибитных каналов есть вполне себе другие решения, которые любой восьмибитный трафик через себя туннелируют. Но для 99% населения, умеющего и желающего общаться только по TCP/IP, это реальный оверхед.

И да, ранее описанный подход мог бы применяться и к POST /u/point:

POST /u/point
Content-Type: text/plain; charset=utf-8

[auth_str]
[message]
.

shaos> Я для себя хочу попробовать новый вызов /u/n с ascii85+ вместо base64 - будет покомпактнее чуток

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

shaos> > мощно я задвинул? внушает? :)

Спасибо, с изначальным подходом к проектированию ii всё ясно.

shaos> в старой "болталке с девочками" hc.51 почти все хеши вида 7lwguohJulissiiuliss и mPJSJAI3ulissiiuliss а в других местах видимо просто отредактированные сообщения без изменения msgid...

И с реализациями тоже.

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

Полностью согласен.

193D2s... . ОТВЕТИТЬ



\/ . shaos to ahamai @ Re: Полуневдимые эхи 27/10/24 03:55

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

TJRyS3... . ОТВЕТИТЬ



\/ . shaos to ahamai @ Re: Полуневдимые эхи 27/10/24 03:52

в старой "болталке с девочками" hc.51 почти все хеши вида 7lwguohJulissiiuliss и mPJSJAI3ulissiiuliss а в других местах видимо просто отредактированные сообщения без изменения msgid...

6GxZso... . ОТВЕТИТЬ



\/ . shaos to shaos @ Re: Полуневдимые эхи 27/10/24 03:48

О - нашёл!!!

https://www.linux.org.ru/forum/talks/10258332?cid=10258568

> return base64.urlsafe_b64encode( hashlib.sha256(s).digest() ).replace('-',").replace('_',")[:20]
> мощно я задвинул? внушает? :)
> feofil (06.03.14 09:41:46 PST) автор топика

Мне интересно в какой момент в реплейсах появились 'A' и 'z'? ;)

Если верить гиту, то 1 апреля 2014 года (в момент создания репы):

a45cdfa3 (user 2014-04-01 19:19:03 +1100 16) def hsh(s):
a45cdfa3 (user 2014-04-01 19:19:03 +1100 17) return base64.urlsafe_b64encode( hashlib.sha256(s).digest() ).replace('-','A').replace('_','z')[:20]

Но я знаю, что первый релиз ii был в начале мерта 2014 года...

nlyTyC... . ОТВЕТИТЬ



\/ . ahamai to shaos @ Re: Полуневдимые эхи 26/10/24 21:46

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

5B8AjW... . ОТВЕТИТЬ



\/ . ahamai to shaos @ Re: xc: lor 26/10/24 21:41

> лор уже не торт...

ну, сейчас в разы адекватнее, чем какой-нибудь 2008, где большинство комментов в новостях и тем в толксах содержали полную ахинею, я тогда на опеннет убежал. и сейчас я "голдифицирую" тему 2000-го года, за несколько дней только до второй страницы дошёл.

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

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

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

KkZN2k... . ОТВЕТИТЬ



\/ . ahamai to shaos @ Re: Полуневдимые эхи 26/10/24 21:35

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

xxG7Ve... . ОТВЕТИТЬ



\/ . ahamai to revoltech @ Re: Полуневдимые эхи 26/10/24 21:34

> вот 3547 сообщений имеют айдишники, которые вообще описанному в доках хэшу не соответствуют. Вопрос: был/имеется ещё какой-то алгоритм хэширования или что за фигня там происходит? А потом коллизиям удивляются.

во всяких босфорах и улиссах длина хэша была где 8, где 12 символов, поэтому для гейтования в ii до 20 добавлялось что-то типа "bosforbosfor" (а в гейтованых месагах вроде где-то полный хэш был, не помню уже, как это всё между сетями летало, но летало успешно.

UtYlIU... . ОТВЕТИТЬ









\/ . shaos to doesnm @ Re: Полуневдимые эхи 26/10/24 19:57

не - base64 нужен т.к. позволяет ii транспорту работать в том числе и по последовательным 7-битным каналам - через COM порт там или прямо в тексте е-мейлов без mime кодирования (которое также в текст по сути)...

DGuLKs... . ОТВЕТИТЬ



\/ . shaos to revoltech @ Re: Полуневдимые эхи 26/10/24 19:53

Я три недели назад уже всё посчитал TfXUY2nZ1vmjAsQhgfsK

Многие узлы допускают редактирование сообщений без изменения хеша и возможно какие-то изначально неправильно хеш реализовывали (т.к. в спеке небыло эталонных сообщений для сверки как это обычно принято) и потом некоторые ботоэхи с какого-то момента стали сломанные: 6kCluOlO0AG8aOvgvRPr

Основные stakeholders (текущий мейнтейнер стандарта с одной стороны и первоначальный создатель с другой) в один голос говорят, что сам алгоритм не важен - главное чтобы msgid был уникальным, поэтому я и отпочковал от ii/IDEC свой strengthened вариант iii т.к. мне для будущих экспериментов важно, чтобы хэш сходился всегда :)

iii.nizya

А вообще было бы сильно прикольнее, если бы история хеширования в ii пошла по другому пути ;)

vTYmGKHeCyvLZ3BV2NoP

Потому что как оказалось сам Создатель упоминал такой способ в комментах на лоре на этапе создания технологии ;)

[линк с пруфом пока не могут отыскать]

F8qxdx... . ОТВЕТИТЬ



\/ . revoltech to ahamai @ Re: Полуневдимые эхи 26/10/24 17:16

ahamai> ну тогда это оверхед в коде. когда я делал, сравнить мне было не с чем, просто сделал на ровном месте, но по http оно работает ровно так, как было сделано в первой версии (хотя я много что забыл, но всё равно как-то работает). поэтому мой вариант естественно не оптимален и не идеален, и если кто-то сделает гораздо красивее, я с радостью перейду на этот формат.

Ну вот, кстати, я начал просто отслеживать хэши сообщений вместе с айдишниками, и после перефетча (со всего, кроме spline-online) из 17614 сообщений 14067 оказались с корректными айдишниками (сравнивал по функции LOWER() в базе, так что нюансы с A-z не важны), а вот 3547 сообщений имеют айдишники, которые вообще описанному в доках хэшу не соответствуют. Вопрос: был/имеется ещё какой-то алгоритм хэширования или что за фигня там происходит? А потом коллизиям удивляются.

Статистика сообщений с левыми ID по эхам (не считая spline):

sqlite> SELECT DISTINCT `echoname`, COUNT(`id`) FROM `msg` WHERE LOWER(`msgid`) != LOWER(`content_id`) GROUP BY `echoname`;
blcat.local|1
develop.16|17
game.rogue.14|39
idec.talks|322
idec.test|13
ii.stat|7
linux.14|341
lit.14|4
lor-opennet.17|1
lor.gold|31
music.14|34
ping.local|4
pipe.2032|1123
plan.9|2
python.15|8
retro.talks|27
ru.humor.14|35
spnet.stats|1
std.club|1241
std.favorites|2
std.game|139
std.hugeping|68
std.hugeping.micro|2
std.prog|36
std.rein|1
std.tech|47
zx.spectrum|1

HQNRuf... . ОТВЕТИТЬ



\/ . ahamai to revoltech @ Re: Полуневдимые эхи 26/10/24 15:46

> Для сообщений: посчитать хэш, преобразовать в айдишник по алгоритму и сравнить с тем айдишником, который в начале строки в бандле.
> Для эх: сравнить количество айдишников с тем, которое мы запрашиваем, и удостовериться в том, что все скачанные айдишники имеют 20 символов.

ну тогда это оверхед в коде. когда я делал, сравнить мне было не с чем, просто сделал на ровном месте, но по http оно работает ровно так, как было сделано в первой версии (хотя я много что забыл, но всё равно как-то работает). поэтому мой вариант естественно не оптимален и не идеален, и если кто-то сделает гораздо красивее, я с радостью перейду на этот формат.

2sTZ8U... . ОТВЕТИТЬ



\/ . revoltech to ahamai @ Re: Полуневдимые эхи 26/10/24 15:30

ahamai> остаётся вопрос в том, как узнать, докачалось ли всё или оборвалось.

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

Для эх: сравнить количество айдишников с тем, которое мы запрашиваем, и удостовериться в том, что все скачанные айдишники имеют 20 символов.

gIQZO1... . ОТВЕТИТЬ



\/ . ahamai to revoltech @ Re: Полуневдимые эхи 26/10/24 15:27

> Кто-нибудь скажет, какие проблемы решает base64 именно при постинге, каких не решает тот же самый x-www-form-urlencoded, в который сообщение по итогу всё равно заворачивается?

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

WZlFtJ... . ОТВЕТИТЬ



\/ . revoltech to doesnm @ Re: Полуневдимые эхи 26/10/24 15:19

doesnm> Го дропнем base64

Для /u/m не получится без глубинного перелопачивания самого формата бандла, а вот для /u/point, в принципе, легко.

Кто-нибудь скажет, какие проблемы решает base64 именно при постинге, каких не решает тот же самый x-www-form-urlencoded, в который сообщение по итогу всё равно заворачивается?

dsUaUR... . ОТВЕТИТЬ



\/ . ahamai to revoltech @ Re: Полуневдимые эхи 26/10/24 14:46

> Пример запроса по Nex: echo /u/e/idec.talks | nc station.domain 1900

остаётся вопрос в том, как узнать, докачалось ли всё или оборвалось. всё равно нужен con-len или какие-то флаги. кстати я изначально хотел добавить, чтобы любой бандл начинался и заканчивался конкретным тегом, чтобы проверять валидность бандла. но банально забыл. но вроде с http ничё так получилось, от этого не страдаем. а новой технологии придётся показывать себя на практике - ждём реализации :)

P2Ra1N... . ОТВЕТИТЬ



\/ . doesnm to revoltech @ Re: Полуневдимые эхи 26/10/24 14:35

shaos>> Меньше это Gopher или Nex овер телнет :)
revoltech> Да не обязательно овер телнет, но да, суть в том, чтобы не относящихся непосредственно к ii метаданных меньше гонять. Здесь и так сообщения в base64 оборачиваются, что уже 4/3 от полезной нагрузки...

Го дропнем base64

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

t0cAH8... . ОТВЕТИТЬ



\/ . ahamai to All @ xc: lor 26/10/24 14:36

Думаю о создании станции lor2ii, которая будет медленно и печально собирать сообщения с текущих тем лора.

Без веб интерфейса, либо с веб интерфейсом только для пойнтов.

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

Сообщения с лора тэгировать чем-то типо lorlink/урл-на-сообщение.

Вернуть http-клиента и ориентировать на всё это.

Кому-нибудь такое интересно?

4NwE99... . цепочка . ОТВЕТИТЬ



\/ . revoltech to shaos @ Re: Полуневдимые эхи 26/10/24 11:56

shaos> Меньше это Gopher или Nex овер телнет :)

Да не обязательно овер телнет, но да, суть в том, чтобы не относящихся непосредственно к ii метаданных меньше гонять. Здесь и так сообщения в base64 оборачиваются, что уже 4/3 от полезной нагрузки...

GpJfTK... . ОТВЕТИТЬ





\/ . revoltech to tuple @ Re: Полуневдимые эхи 26/10/24 11:06

tuple> Почему жирный-то? Почти натуральный plaintext. Куда меньше?

Потому что статусы и заголовки, например. См. как в гофере или нексе сделано: строка запроса — ответ, всё.

Пример запроса по Nex: echo /u/e/idec.talks | nc station.domain 1900

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

Отвечаю заранее на вопрос «а как же постить»? Как в NPS — на другой порт:

cat <<EOF | nc station.domain 1915
/u/point
[auth_string]
[base64_message]
.
EOF

Вот тут уж действительно меньше некуда.

P.S. Что-то не смог запостить на sprinternet, переслал на tgi.

k2ZkiF... . ОТВЕТИТЬ



\/ . revoltech to tuple @ Re: Полуневдимые эхи 26/10/24 11:09

tuple> Почему жирный-то? Почти натуральный plaintext. Куда меньше?

Потому что статусы и заголовки, например. См. как в гофере или нексе сделано: строка запроса — ответ, всё.

Пример запроса по Nex: echo /u/e/idec.talks | nc station.domain 1900

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

Отвечаю заранее на вопрос «а как же постить»? Как в NPS — на другой порт:

cat <<EOF | nc station.domain 1915
/u/point
[auth_string]
[base64_message]
.
EOF

Вот тут уж действительно меньше некуда.

WTbH8A... . ОТВЕТИТЬ





\/ . revoltech to ahamai @ Re: Полуневдимые эхи 26/10/24 06:03

ahamai> ну 16 норм, но потом бы я шаги увеличивал, там 64, потом 256 потом все сообщения. или вообще 16 если чё-то не хватает то забирать все. думаю, такие триггеры будут редко срабатывать.

Сделал у себя с шагом кратности 12 (потом 24, 48 и т.д.), чтобы в самом распространённом случае можно было даже с tgi и подобных за один запрос стянуть.

ahamai> стоп. -16:1 - это взять один хэш? а почему не -16:16? или я что-то не понял.

Ну в том алгоритме главная идея состоит в экономии трафика, полагаю. Сначала пробный запрос с -16:1, а потом, если в базе есть сообщение, то можно и -16:16.

EV9xq1... . ОТВЕТИТЬ



\/ . revoltech to Andrew Lobanov @ Re: Полуневдимые эхи 26/10/24 05:48

AL> Потому что документация описывает IDEC.

Возникает вопрос: её здесь вообще кто-нибудь ещё читал?

Первый же абзац в https://github.com/idec-net/new-docs/blob/master/extensions.md:

> Здесь описаны расширения протокола, являющиеся основным отличием IDEC от ii. Многие из них реализовывать совсем необязательно.

И далее чуть ниже пункт «Список эхоконференций», описывающий GET /list.txt.

То есть документация называет GET /list.txt одним из основных отличий IDEC от ii. А мне тут рассказывают, что «это было в ii». Ну так документацию тогда поправьте, если это было в ii, а не эксклюзив IDEC.

Я вот вместе с кодобазой tii начал вести свой ii-doc.txt, где описываю только реализованные в tii части протокола. И с пометкой IDEC extension у меня там только GET /x/features и один из вариантов /u/e, который со слайсами.

AL> Слишком много оверхеда.

Слишком много сарказма. Если уж позиционируем протокол как альтернативу щитвебу и если уж спецификация не обязывает именно к HTTP(S)-транспорту (опять гитхаб процитировать?), то вполне логично принимать и предложения по более легковесным протоколам вместо упора в жирный HTTP(S).

I5hIe1... . ОТВЕТИТЬ





\/ . shaos to Andrew Lobanov @ Re: Стандарт 25/10/24 21:17

>ahamai> предлагаю включить в стандарт возможность исполнения list.txt?h=1

>Что это должно делать?

Возвращать хеши эх вместо дескрипшина:

====
idec.talks:1699:hsh/wHerzeypz8j1d8tviSRh
blcat.local:6:hsh/kAIYYMMc5DWK0FJhsW64
retro.talks:62:hsh/bahvlLwAzK2ArGHvXWat
bot.habr.rss:157:hsh/dwqigyrvKJQURxn88dwq
lor.opennet:127:hsh/12hqQwDfGoRXxD5ILIfj
ru.humor.14:817:hsh/4GxIyw2R69G75LlwnG0r
lor.gold:47:hsh/f4BQcuDnC7LTwzQHZ42k
linux.14:919:hsh/k8AiOJGrmMm1Q30W0Stz
====


oKCeD3... . ОТВЕТИТЬ



\/ . Andrew Lobanov to hugeping @ Re: Стандарт 25/10/24 20:06

AL>> Итак, меня тут назначили главным по стандарту. Моё предложение такое: убрать фреки, убрать фэхи, убрать счётчики
hugeping> Я тут понял, что если счётчики будут настоящими счётчиками сообщений (без требования не расти вниз), то совместно с слайсами они дают возможность писать клиента который не скачивает сообщения в базу а просто просматривает их онлайн. То-есть:
hugeping> 1) получили счётчики
hugeping> 2) нарисовали пагинатор
hugeping> 3) по мере "листания" пользователя - проходим сообщения слайсами
hugeping> Если убрать x/c то будет неполнота. Короче я за то, чтобы счётчики стали настоящими.

Мысль интересная, но я бы за такие манипуляции со своей станцией карал :)

hugeping> P.S. Хотя у нас есть list.txt где эти счётчики тоже присутствуют, но их надо парсить....

Там они показывают фактическое количество сообщений. То есть могут иметь отрицательный рост :)

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

gpRAcz... . ОТВЕТИТЬ



\/ . Andrew Lobanov to ahamai @ Re: Стандарт 25/10/24 20:06

ahamai> предлагаю включить в стандарт возможность исполнения list.txt?h=1

Что это должно делать?

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

YA6yml... . ОТВЕТИТЬ



\/ . Andrew Lobanov to ahamai @ Re: А что с эхой lor.opennet? 25/10/24 20:06

ahamai> Андрей, а что с rss-гейтом? Мёртв с 16 числа.

Умер.

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

hbd3wv... . ОТВЕТИТЬ



\/ . Andrew Lobanov to shaos @ Re: Стандарт 25/10/24 20:06

shaos> а количество плюсиков не равно обратной карме? ;)

Нет :)

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

9X6xI4... . ОТВЕТИТЬ



\/ . Andrew Lobanov to revoltech @ Re: Полуневдимые эхи 25/10/24 20:06

AL>> Это было в ii.
revoltech> А почему документация описывает это как IDEC-расширение?

Потому что документация описывает IDEC.

AL>> Внимание! Вопрос: какая у тебя OS и какое окружение? Пользуешься веб-браузером?
revoltech> К сожалению, пользуюсь. К вопросу об ОС и окружении — Alpine Linux, X/Fluxbox.

Слишком много оверхеда.

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

GuQtx2... . ОТВЕТИТЬ



\/ . ahamai to hugeping @ Re: Стандарт 25/10/24 19:14

> Мне идея хешей эх не нравится.

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

> Придётся хранить состояние последнее на диске при фетче.

хранить предыдущий list.txt, только и всего. зато меньше лишних запросов, большинство эх перманентно мёртвые. я жду, когда shaos сделает ?h=1, чтобы под это фетчеры адаптировать и не гонять лишнее.

gTbFgj... . ОТВЕТИТЬ





\/ . hugeping to ahamai @ Re: Мея видо? 25/10/24 19:07

ahamai> я даже не помнил, как сервер называется :) gmid оказывается, нашёл, включил

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

BYcMCo... . ОТВЕТИТЬ



\/ . hugeping to shaos @ Re: Стандарт 25/10/24 19:06

shaos> Даже пример реализации пролетал :)

Мне идея хешей эх не нравится. Придётся хранить состояние последнее на диске при фетче. Теряется эстетика простоты. Кроме того, сплайсы и так решают эту проблему (но более элегантно). В общем я понял, стандарт лучше не трогать!

KXRoPW... . ОТВЕТИТЬ











\/ . ahamai to hugeping @ Re: Полуневдимые эхи 25/10/24 18:14

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

стоп. -16:1 - это взять один хэш? а почему не -16:16? или я что-то не понял.

J27tU3... . ОТВЕТИТЬ









\/ . hugeping to ahamai @ Re: Мея видо? 25/10/24 18:01

ahamai> открыл в lynx, попытался перейти в веб, пишет "ошибка документа"

А я хотел заценить твой гемини и... лежит... :(

XHApgT... . ОТВЕТИТЬ



\/ . hugeping to ahamai @ Re: Мея видо? 25/10/24 17:53

ahamai> кстати, а зачем ты меня вообще фетчишь? :) мой аплинк shaos, мы меняемся с ним трафиком, и уже от него по идее он должен попадать в остальную сеть. типа чтобы сообщения быстрее доходили?

Я и не фетчу (пока). Я тебе писал как к автору инициативы форвардить из теста в talks. :)

lnf46v... . ОТВЕТИТЬ



\/ . hugeping to ahamai @ Re: Стандарт 25/10/24 17:51

ahamai> предлагаю включить в стандарт возможность исполнения list.txt?h=1

А что это значит, напомни?

9xnBcv... . ОТВЕТИТЬ



\/ . hugeping to ahamai @ Re: Полуневдимые эхи 25/10/24 17:47

ahamai> Зачем столько запросов? Это и лишняя нагрузка на сервер, и лишний трафик (хедеры, все дела).

Напиши конкретный алгоритм, я не понял твоё предложение.
Начинаю я с -16:1 - я там выше написал что лимит это параметр. В описании алгоритма я для понятности задал его в 1, но в быту мы начинаем не с 1. И обычно, если сообщений < 16 новых это единственный запрос. Если нет, будет -32:1, потом -64:1....

87tzFw... . ОТВЕТИТЬ



\/ . ahamai to hugeping @ Re: Стандарт 25/10/24 17:54

клиент, просматривающий сообщения онлайн, без слайсов и прочего

====
for n in `wget -q -O - http://ii.blcat.ru/e/idec.talks | tac`
do
wget -q -O - http://ii.blcat.ru/m/$n | less
done
====



переключаться клавишей q :)

rpzzk4... . ОТВЕТИТЬ



\/ . hugeping to Andrew Lobanov @ Re: Стандарт 25/10/24 17:34

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

Я тут понял, что если счётчики будут настоящими счётчиками сообщений (без требования не расти вниз), то совместно с слайсами они дают возможность писать клиента который не скачивает сообщения в базу а просто просматривает их онлайн. То-есть:

1) получили счётчики
2) нарисовали пагинатор
3) по мере "листания" пользователя - проходим сообщения слайсами

Если убрать x/c то будет неполнота. Короче я за то, чтобы счётчики стали настоящими.

P.S. Хотя у нас есть list.txt где эти счётчики тоже присутствуют, но их надо парсить....

CmrT5o... . ОТВЕТИТЬ









\/ . shaos to Andrew Lobanov @ Re: Полуневдимые эхи 25/10/24 17:10

> Это было в ii.

А почему тогда list.txt и blacklist.txt перечисляется в /x/features?

====
curl -XGET http://idec.spline-online.ru/x/features
u/e
list.txt
blacklist.txt
x/file
x/small-echolist
x/caesium
x/c
====


О - кстати, а что такое x/small-echolist?

jNCPgI... . ОТВЕТИТЬ





\/ . revoltech to Andrew Lobanov @ Re: Полуневдимые эхи 25/10/24 16:55

AL> Это было в ii.

А почему документация описывает это как IDEC-расширение?

AL> Внимание! Вопрос: какая у тебя OS и какое окружение? Пользуешься веб-браузером?

К сожалению, пользуюсь. К вопросу об ОС и окружении — Alpine Linux, X/Fluxbox.

R89fbL... . ОТВЕТИТЬ





\/ . Andrew Lobanov to hugeping @ Re: Мея видо? 25/10/24 16:29

hugeping> P.S. Когда цезий возродишь? :)

Цезий ждёт похорон. Допилю ноду, продолжу пилить цезий+ :)

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

gA4KwC... . ОТВЕТИТЬ



\/ . Andrew Lobanov to All @ Стандарт 25/10/24 16:26

Итак, меня тут назначили главным по стандарту. Моё предложение такое: убрать фреки, убрать фэхи, убрать счётчики, оставить только e/, m/, u/e (со слайсами), u/m, u/point, u/push, list.txt, blacklist.txt. Остальное выпилить нафиг.

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

Продумать систему наказаний поинтов (накопление плюсиков, перевод в "только чтения", отключение от эхи) на уровне стандарта.

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

1t0CZs... . цепочка . ОТВЕТИТЬ



\/ . Andrew Lobanov to shaos @ Re: Полуневдимые эхи 25/10/24 16:26

>> Но вред файлэх в чём?
shaos> 1. Там передаётся нетекстовая информация т.е. через терминал уже не будет работать

Постоянно работаю с файлами в терминале.

shaos> 2. Функционально файл из файлэхи это просто забирание файла по HTTP - зачем городить лишние абстракции?

Транспорт может быть любым.

shaos> 3. Сейчас (на таверне) оно используется в основном только для раздачи порнухи и пиратских книг...

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

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

6HHFwU... . ОТВЕТИТЬ



\/ . Andrew Lobanov to revoltech @ Re: Полуневдимые эхи 25/10/24 16:26

AL>> Удивительно. 9 лет у всех всё доходит, а у тебя нет. Может, надо что-то в фетчере поменять?
revoltech> Наверное, мы о разных вещах говорим.
revoltech> 1. Фетчер по server-side слайсу качает 100 последних сообщений вечером.
revoltech> 2. За ночь в эхе появляется 103 сообщения.
revoltech> 3. Фетчер по server-side слайсу качает 100 последних сообщений утром.
revoltech> Вопрос знатокам: увидит ли клиент те несчастные три сообщения?

Зачем брать сто, а не то, чего у тебя нет?

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

Внимание! Вопрос: какая у тебя OS и какое окружение? Пользуешься веб-браузером?

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

EYA51R... . ОТВЕТИТЬ



\/ . Andrew Lobanov to revoltech @ Re: Полуневдимые эхи 25/10/24 16:12

shaos>> И кстати зачем родили IDEC если ii был такой уютненький и самодостаточный? ;)
revoltech> Да вот не знаю, кстати, мне пока что только расширение с list.txt полезным показалось.

Это было в ii.

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

ZXh7Uk... . ОТВЕТИТЬ



\/ . hugeping to hugeping @ Re: Полуневдимые эхи 25/10/24 15:34

hugeping> Я тут подумал и понял, что не могу предложить никакого другого варианта фетчинга. Кроме того, что сделал в ii-go (на основе слайсов). Опишу варианты, которые рассматривал.

hugeping> 1) Вариант с запросом "дай мне все, что позже такого-то хеша" не сработает так как порядок сообщений в базе может быть разным;

Хотя, сработает. Если брать с разумным "запасом" на самом деле... Правда опять вопросы с блеклистами и удалениями могут быть.

WFG6T1... . ОТВЕТИТЬ



\/ . hugeping to hugeping @ Re: Полуневдимые эхи 25/10/24 15:32

Я тут подумал и понял, что не могу предложить никакого другого варианта фетчинга. Кроме того, что сделал в ii-go (на основе слайсов). Опишу варианты, которые рассматривал.

1) Вариант с запросом "дай мне все, что позже такого-то хеша" не сработает так как порядок сообщений в базе может быть разным;

2) Вариант с хешом эхи как индикатором изменений - не решает проблему забирать не всё, а только часть. Да и предполагает хранить на диске или в базе последний хеш;

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

4) Вариант возвращать список id в обратном порядке. Идея в том что если я получаю список в обратном порядке я могу закрыть соединение в тот момент когда мне уже больше не надо. :) Но, как-то на хак похоже. А как вам? Не знаю... Нет красоты.

Получается, ничего проще слайсов и не сделать? :)

fNjAY1... . ОТВЕТИТЬ




1 2 3 4 5 6 7 8 9 10 11 .12. 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31