Re: Полуневдимые эхи
Ответ на сообщение
revoltech> жирный HTTPПочему жирный-то? Почти натуральный plaintext. Куда меньше?
tuple to revoltech (2024-10-26 09:39:47)
[ссылка]
revoltech> жирный HTTPПочему жирный-то? Почти натуральный plaintext. Куда меньше?
ahamai> ну 16 норм, но потом бы я шаги увеличивал, там 64, потом 256 потом все сообщения. или вообще 16 если чё-то не хватает то забирать все. думаю, такие триггеры будут редко срабатывать.Сделал у себя с шагом кратности 12 (потом 24, 48 и т.д.), чтобы в самом распространённом случае можно было даже с tgi и подобных за один запрос стянуть.
ahamai> стоп. -16:1 - это взять один хэш? а почему не -16:16? или я что-то не понял.Ну в том алгоритме главная идея состоит в экономии трафика, полагаю. Сначала пробный запрос с -16:1, а потом, если в базе есть сообщение, то можно и -16:16.
AL> Потому что документация описывает IDEC.Возникает вопрос: её здесь вообще кто-нибудь ещё читал?
> Здесь описаны расширения протокола, являющиеся основным отличием IDEC от ii. Многие из них реализовывать совсем необязательно.И далее чуть ниже пункт «Список эхоконференций», описывающий GET /list.txt.
AL> Слишком много оверхеда.Слишком много сарказма. Если уж позиционируем протокол как альтернативу щитвебу и если уж спецификация не обязывает именно к HTTP(S)-транспорту (опять гитхаб процитировать?), то вполне логично принимать и предложения по более легковесным протоколам вместо упора в жирный HTTP(S).
>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
ahamai> Андрей, а что с rss-гейтом? Мёртв с 16 числа.Умер.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
ahamai> предлагаю включить в стандарт возможность исполнения list.txt?h=1Что это должно делать?
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
AL>> Итак, меня тут назначили главным по стандарту. Моё предложение такое: убрать фреки, убрать фэхи, убрать счётчикиМысль интересная, но я бы за такие манипуляции со своей станцией карал :)
hugeping> Я тут понял, что если счётчики будут настоящими счётчиками сообщений (без требования не расти вниз), то совместно с слайсами они дают возможность писать клиента который не скачивает сообщения в базу а просто просматривает их онлайн. То-есть:
hugeping> 1) получили счётчики
hugeping> 2) нарисовали пагинатор
hugeping> 3) по мере "листания" пользователя - проходим сообщения слайсами
hugeping> Если убрать x/c то будет неполнота. Короче я за то, чтобы счётчики стали настоящими.
hugeping> P.S. Хотя у нас есть list.txt где эти счётчики тоже присутствуют, но их надо парсить....Там они показывают фактическое количество сообщений. То есть могут иметь отрицательный рост :)
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
AL>> Это было в ii.Потому что документация описывает IDEC.
revoltech> А почему документация описывает это как IDEC-расширение?
AL>> Внимание! Вопрос: какая у тебя OS и какое окружение? Пользуешься веб-браузером?Слишком много оверхеда.
revoltech> К сожалению, пользуюсь. К вопросу об ОС и окружении — Alpine Linux, X/Fluxbox.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
shaos> а количество плюсиков не равно обратной карме? ;)Нет :)
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
> Мне идея хешей эх не нравится.ну это самый надёжный способ показать, изменилась эха или нет. только два состояния, эха изменилась и эха не изменилась. изменилась фетчим, не изменилась не фетчим. две строки кода для сервера и несколько строк для фетчера
> Придётся хранить состояние последнее на диске при фетче.хранить предыдущий list.txt, только и всего. зато меньше лишних запросов, большинство эх перманентно мёртвые. я жду, когда shaos сделает ?h=1, чтобы под это фетчеры адаптировать и не гонять лишнее.
ahamai> я даже не помнил, как сервер называется :) gmid оказывается, нашёл, включилНу то есть это будет заброшено при первом же ребуте сервера? Ок, тогда не буду пока добавлять в ссылки на своей капсуле.
shaos> Даже пример реализации пролетал :)Мне идея хешей эх не нравится. Придётся хранить состояние последнее на диске при фетче. Теряется эстетика простоты. Кроме того, сплайсы и так решают эту проблему (но более элегантно). В общем я понял, стандарт лучше не трогать!
> Мне нравится идея, что у каждого свой суверенный блеклист :)ну сейчас - да, и в принципе это норм
ahamai> открыл в lynx, попытался перейти в веб, пишет "ошибка документа"А я хотел заценить твой гемини и... лежит... :(
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 :)
ahamai> кстати, а зачем ты меня вообще фетчишь? :) мой аплинк shaos, мы меняемся с ним трафиком, и уже от него по идее он должен попадать в остальную сеть. типа чтобы сообщения быстрее доходили?Я и не фетчу (пока). Я тебе писал как к автору инициативы форвардить из теста в talks. :)
ahamai> предлагаю включить в стандарт возможность исполнения list.txt?h=1А что это значит, напомни?
ahamai> Зачем столько запросов? Это и лишняя нагрузка на сервер, и лишний трафик (хедеры, все дела).Напиши конкретный алгоритм, я не понял твоё предложение.
AL> Итак, меня тут назначили главным по стандарту. Моё предложение такое: убрать фреки, убрать фэхи, убрать счётчикиЯ тут понял, что если счётчики будут настоящими счётчиками сообщений (без требования не расти вниз), то совместно с слайсами они дают возможность писать клиента который не скачивает сообщения в базу а просто просматривает их онлайн. То-есть: