revoltech> P.S. Да, ещё раз пардон, перепроверил — то у tgi только 12 сообщений за раз можно выгрести. У остальных 389, у тебя вообще лимит 10000 вроде хавает без проблем. Правда, spline-online не тестил, он и так еле живой сейчас.

Кстати, это соответствует "рекомендованному" буферу в 8к. Как раз ~380 id-шников. 12 сообщений это, конечно, маловато даже по меркам "обычного" веба.

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

Ну и есть всякие плюшки типа минимальной гарантии доставки (content-len, или если что-то пошло не так, брякнулись с ошибкой и клиент понял что ошибка). Плюс опциональное gzip сжатие, существующее с лохматых годов. Правда, сейчас py3 фетчер не поддерживает gzip сжатие, py2 и ii-txt на py2 поддерживают. Сейчас глянул, у меня на сервере не включён gzip для text/plain, включил.

Это хорошо и замечательно, если будут другие транспорты. Но подразумевается, что протокол настолько простой то эти транспорты пишет тот, кто этим интересуется. Для меня простота - это возможность в несколько строк написать фетчер хоть на python, хоть на busybox, поэтому я буду поддерживать реализацию только через http. Но всегда интересно посмотреть на сторонние проекты.

увеличил буферы в nginx. скормил url на 89 кбайт - сожрало

ahamai> Ну и есть всякие плюшки типа минимальной гарантии доставки

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

ahamai> Для меня простота - это возможность в несколько строк написать фетчер хоть на python, хоть на busybox, поэтому я буду поддерживать реализацию только через http. Но всегда интересно посмотреть на сторонние проекты.

Мысль понял, никого не заставляю, но nc и awk имеются и в busybox (как, впрочем, и декодер base64).

ahamai> увеличил буферы в nginx. скормил url на 89 кбайт - сожрало

Так и оставил? Я могу быть уверенным, что выгребу 4238 сообщений за один запрос?

Тестируем многострочный пост, как я бы его обычно писал в виме до того, как
допилю GUI-клиента.

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

И да, спасибо shaos за доступ, будем тестить в idec.test дальше.

[forwarded from idec.test]

видо :)

[forwarded from idec.test]

revoltech> Тестируем многострочный пост, как я бы его обычно писал в виме до того, как
revoltech> допилю GUI-клиента.
revoltech> Если всё нормально, то сегодня или на днях сделаю вообще длиннопост о том,
revoltech> что покамест думаю об этой сети и её перспективах.
revoltech> И да, спасибо shaos за доступ, будем тестить в idec.test дальше.

ВИД О. Только откуда-то лишние переводы строки лезут.

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

[forwarded from idec.test]

Ну может так задумано? Типа пустая строка между абзацами?…

[forwarded from idec.test]

Перепутал поля местами, бывает. С GUI-клиентом путать не буду.

[forwarded from idec.test]

shaos> Ну может так задумано? Типа пустая строка между абзацами?…

Я про переносы внутри абзаца.

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

[forwarded from idec.test]

А, да, так тоже задумано. Держу строку в пределах 80 символов. Не автоматом, вручную.

[forwarded from idec.test]

Не - тут это ненужно

Длинные строки сами разбиваются при выводе

[forwarded from idec.test]

revoltech> А, да, так тоже задумано. Держу строку в пределах 80 символов. Не автоматом, вручную.

Это чтобы твои сообщения было неудобно читать на мобильных устройствах и в узких окнах или зачем?

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

[forwarded from idec.test]

Это для того, чтобы удобнее читалось в терминале на клиентах без reflow. Хотя, я так понимаю, таковых здесь нет, поэтому буду отказываться от своей гоферистской привычки. Ну и то, что GUI-клиент уже более-менее юзабелен, тоже этому способствует.

[forwarded from idec.test]

Погоди, а гофер-клиенты чтоли не умеют строки переносить?

Кстати где можно твой гофер почитать? ;)

[forwarded from idec.test]

Во, вылезло ещё одно место, где trim не делался, щас должно быть нормально.

[forwarded from idec.test]

Умеют, но далеко-далеко не все, я вон раньше на баше вообще пилил со своим reflow...

Я на gopher://hoi.st обитаю, если что.

[forwarded from idec.test]

о - нашёл сырцы tii :)
публик домейн это круто!

[forwarded from idec.test]

Насчёт tii/tiix, как и насчёт ii вообще, в понедельник свежий псто в гофер выкачу. Уже точно есть что сказать. В idec.talks тоже что-то длиннотекстовое на днях появится, думаю.

А так да, я давно уже свой софт в public domain выкладываю, мне ограничения ни с одной из сторон (как копирайта, так и копилефта) не импонируют. Ну и Tcl/Tk, особенно начиная с 8.6, настолько хорош, что позволяет в довольно ограниченные сроки пилить вещи типа tiix и BFG. На sqlite3 мигрировать, конечно, не хотелось, но пришлось: некоторые ноды отдают сообщения не по порядку их фактической публикации (видимо, смёржены позже), поэтому, чтоб не сортировать на лету, пришлось сортировать уже скулайтом при выводе.

[forwarded from idec.test]

> некоторые ноды отдают сообщения не по порядку их фактической публикации

да - есть такое дело

я себе что забираю кучно потом пересортирую вручную, если совсем страшно напутано

[forwarded from idec.test]

revoltech> Насчёт tii/tiix, как и насчёт ii вообще, в понедельник свежий псто в гофер выкачу. Уже точно есть что сказать. В idec.talks тоже что-то длиннотекстовое на днях появится, думаю.
revoltech> А так да, я давно уже свой софт в public domain выкладываю, мне ограничения ни с одной из сторон (как копирайта, так и копилефта) не импонируют. Ну и Tcl/Tk, особенно начиная с 8.6, настолько хорош, что позволяет в довольно ограниченные сроки пилить вещи типа tiix и BFG. На sqlite3 мигрировать, конечно, не хотелось, но пришлось: некоторые ноды отдают сообщения не по порядку их фактической публикации (видимо, смёржены позже), поэтому, чтоб не сортировать на лету, пришлось сортировать уже скулайтом при выводе.

А потом с дальней станции прилетает сообщение полугодовой давности :)

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

[forwarded from idec.test]

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

Зачем сортировать то, что фактически является множеством?

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

[forwarded from idec.test]

Затем что ii-php показывает в том прядке в каком сохранено, а там может быть не хронологический порядок…

[forwarded from idec.test]

shaos> Затем что ii-php показывает в том прядке в каком сохранено, а там может быть не хронологический порядок…

И это только плюс, так как снижает шансы потеряться старому сообщению, недавно пришедшему на станцию.

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

[forwarded from idec.test]

> А потом с дальней станции прилетает сообщение полугодовой давности :)

Ну, ради такого можно добавить ещё одну галочку — сортировать не хронологически, а по внутреннему id в базе, который сохраняет именно порядок добавления туда. Делов-то...

Наверное, добавлю-таки. Но по дефолту всё равно оставлю хронологическую сортировку.

[forwarded from idec.test]

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

[forwarded from idec.test]

Ну с эхами которые давно живут и пополняются натуральным путём всё плюс минус ок - проблемы возникают у архивных эх, которые вытаскивают из небытия и которые прошли несколько этапов архивирования (бандлы-разбандлы и т д) и перепутались…

[forwarded from idec.test]

Ну я использую ii-php в его оригинальном виде когда эхи и мессаги живут в файлах…

[forwarded from idec.test]

> А потом с дальней станции прилетает сообщение полугодовой давности :)

Ну пока сеть IDEC не настолько разросшаяся и медленная чтобы какие-то ответы бродили месяцами ;)

[forwarded from idec.test]

видо, видо. влил архив с idec.test, так как не у всех она есть. для истории.

ahamai> видо, видо. влил архив с idec.test, так как не у всех она есть. для истории.

Слушай, ну зачем этот хаос. Я вот осознанно не фетчу idec.test. Без предупреждения.
Снимаю пока фетч и занимаюсь зачисткой.

hugeping> Слушай, ну зачем этот хаос. Я вот осознанно не фетчу idec.test. Без предупреждения.
hugeping> Снимаю пока фетч и занимаюсь зачисткой.

Фух. Зачистил. Оставил только один топик Re: Мея видно? так как он хотя бы с нормальными repto: выстраивается в одну тему.

Вообще, я начал думать что нужны фильтры того, что от кого брать...

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

Если же это ленты как в современных соцсетях - то вроде проблем нет. Идёт поток флуда и всё...

То же касается и сообщений. Дико раздражают сообщения однострочники. Но, у всех своя политика и свои правила. И это всё в целом должно как-то работать....

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

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

>> Для того, чтобы её не было, нужно писать дополнительный код, который по идее вообще вредный, так как удобную фишку убирает….
shaos> Ну например можно выкинуть «вообще вредный» код файлэх, который сейчас чуть ли не половину всего кода ii-php занимает :)

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

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

>> Точно был способ в документации. Посмотрите подробней.
revoltech> Да уже всё перерыл, никак не нахожу, как именно клиентом выкачать все сообщения из указанных в /u/e за один HTTP-запрос.
revoltech> Так-то у меня и так выкачиваются только те сообщения, ID которых ещё нет в базе. Но проблемы с ограничением длины GET-строки на сервере это не решает.
revoltech> Самым очевидным решением было бы, наверное, разрешить ещё и HTTP POST /u/m с тем же синтаксисом.

У тебя трафик платный и тарифицируется по количеству HTTP-запросов?

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

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

Никуда не девается эта возможность. Скрытые эхи работают точно так же, как и те, что в list.txt.

shaos> Ну и чисто административный момент - даже если сисоп временно потерял физический доступ к узлу (уехал в отпуск) у него должна оставаться возможность видеть что там происходит пользуясь открытыми апи (напрямую либо через ботов)…

Навернуть расширение для себя было бы лучше, чем ломать удобные фичи.

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

shaos> Ну это можно решить путём объединения эх в тематические группы (которые будут иметь смысл только на уровне узла и не будут задевать сам протокол) - например для временных или мелких эх может существовать тематическая группа unsorted…

Опять какие-то костыли :)

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

shaos>> Объясню - по мне так должна быть возможность программно вытянуть весь контент узла любому кто не есть админ узла (причём через веб можно возможности и поурезать т.к. вебом не только люди пользуются), а со скрытыми эхами такой возможности нет.
revoltech> Так, может, лучше тогда автоматизировать их добавление в list.txt, то есть сделать их НЕ скрытыми, вместо урезания полезной фичи?

Вот. Товарищ дело говорит!

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

shaos> При наличии групп эх наверное можно таки дать возможность пользователям (с высокой кармой?) создавать новые публичные эхи в группе unsorted - эдакий crowd sourcing получится, но по умолчанию такие эхи должны будут быть скрыты от веба (хоть и будут перечислены в list.txt)..,

Божечки! Уже и карма. Куда катецо федо!

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

shaos> А может не будем про политику?…

Ну раз уж начали, то давайте. Чего уж там?

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

shaos> Ну это издевательство над здравым смыслом когда одной рукой вы разрешаете декларировать поддерживаемые фичи через features, а другой запрещаете эти фичи расширять…

Я ничего никому не запрещаю и не разрешаю. Просто считаю отламывание фундаментальных фич вредительством.

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

shaos>> Это да :)
revoltech> Так всё-таки есть стандартный и поддерживаемый вариант, чтобы полный перефетч эхи делался не кучей мелких запросов по 12 айдишников из-за ограничений хттпшного гета на сервере, а чем-то более вменяемым? Или нет? В доках ничего, кроме GET /u/m, по этому поводу не нарыл.

Потому что только GET и есть.

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

shaos> Фуф, а я уж думал выяснится, что Лобанов - квадробер :)

Я сам думал уже кто же я. Квадробер, зацепер, видеоблоггер или, извиняюсь, рэпер. Но пронесло :)

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

iiii> Я не понимаю, как это работает, я не знаю как запросить последние n сообщений и я не понимаю, зачем мне запрашивать кусок эхи не до конца, а посредине. Количество сообщений я считаю ненадёжным источником, можно удалить 1 и жобавить 1 и эха вроде не изменится. , в отличие от хэша. Я вообще при делании срезов не понимаю, что входит а что не входит. Поэтому у меня на станции нет постраничного вывода :)

/u/e/idec.talks/-100:100

заберёт последние 100 сообщений.

iiii> А lim совместим со всем, хоть с ii txt 0.1, меняется только строка в конфиге.

При этом будет работать и /lim/200/u/m и /lim/200/u/point?

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

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

Только если узел, внезапно, пишет в середину индекса, а не только в конец.

revoltech> Мой юзкейс — зашёл утром, запустил tiifetch.tcl или нажал на кнопочку Fetch all echos в tiix, клиент докачает изменения всех эх за ночь и в течение дня дофетчиваю только новое содержимое конкретно интересующих эх, вручную жмякая на Fetch this echo при необходимости. За это время в них может собраться куда больше 100 сообщений, и в случае слайсинга ещё на серверной части до клиента они уже не дойдут никогда.

Удивительно. 9 лет у всех всё доходит, а у тебя нет. Может, надо что-то в фетчере поменять?

revoltech> Поэтому придерживаться базового протокола мне пока кажется более разумным, только вот с выгребанием по /u/m надо что-то решать. 12 айдишников на запрос — слишком мало, а многопоточность всё равно не решает проблему с кучей TCP-соединений и HTTP-метаданных.

У тебя соединения платные или что?

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

shaos> Кстати вопрос про POST в /u/m периодически поднимался, например вот тут ii://w6o5S9CleUqqm4Lgc8O9 (декабрь 2021) что так ни к чему и не привело - вот полное обсуждение:

Потому что это не решает никаких реальных проблем на самом деле. Можно, и было бы даже красиво, отказаться от HTTP, гонять всё через сокеты прямо и вот это вот всё. Отказаться от мелких пакетов и гонять сразу многомегабайтные бандлы. Добавить аватарки, карму, модераторство и бэкдоры для товарища майора. Только зачем?

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

>> если IDEC уже имеет все средства как часть стандарта, то зачем для него городить кастомные гейты?..
ahamai> Без гейта ты нормально не отобразишь ничего ни на zx spectrum ни на msdos, ни на atari st. Сначала научи их utf8 :)

Тоже мне бином Ньютона, utf8 оттранслировать.

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

Например, пагинация индекса в условиях малого объёма оперативной памяти.

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

shaos>> Кстати вопрос про POST в /u/m периодически поднимался, например вот тут ii://w6o5S9CleUqqm4Lgc8O9 (декабрь 2021) что так ни к чему и не привело - вот полное обсуждение
revoltech> И там AL написал, что POST /u/m не решает ни одной проблемы. Как же не решает, если решает? Вот вам проблема: куча лишних соединений и метаданных, т.к. владельцы станций ограничивают длину GET-запросов, либо сознательно, либо оставляя дефолт на веб-сервере. С POST запрос будет всегда одним в идеале.

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

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

ahamai>> Сегментирование запросов было введено специально.
revoltech> Чтобы создать новым поинтам затруднения с первым выкачиванием эх (а-ля блокчейн монеро)?

Новый поинт нажал кнопку "скачать" и скачал. Какие у него могут быть проблемы с первым выкачиванием эх? Или это у старлинка платное открытие нового соединения?

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