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

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

> Для того, чтобы её не было, нужно писать дополнительный код, который по идее вообще вредный, так как удобную фишку убирает….

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

> Очень сильно снижает количество трафика.

Это да :)

TOP10 VISITORS:

[1] 145.224.100.x point=136 web=31 up=53.3MB (45%) <--- 145.224.100.x (6/hr)
[2] Google point=8 web=1298 up=20.8MB (17%) <--- Google
[3] 176.109.111.x point=48 web=0 up=16.8MB (14%) <--- tavern (2/hr)
[4] 217.197.116.x point=142 web=0 up=12.1MB (10%) <--- blackcat (6/hr)
[5] 92.63.98.x point=72 web=0 up=5.2MB (4%) <--- tgi (3/hr)
[6] 95.165.9.x point=145 web=4 up=3.3MB (2%) <--- ping (6/hr)
[7] 185.220.101.x point=4 web=0 up=1.0MB (<1%) <--- 185.220.101.x
[8] 24.130.121.x point=3 web=62 up=0.8MB (<1%) <--- spnet
[9] Facebook point=0 web=51 up=0.5MB (<1%)
[10] 179.43.159.x point=1 web=0 up=0.4MB (<1%) <--- 179.43.159.x

TOTAL TRAFFIC: 116MB

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

Первые 2 фичи интересные, а по лимитам вроде у IDEC логичнее получается

Но тем не менее - девочка та же :)

> а что за расширение list.txt?

Видимо имелось ввиду что

GET /list.txt

появился только в IDEC - спецификация перечисляет это в расширениях

или оно в ранних версиях ii тоже было?

> я не знаю как запросить последние n сообщений

допустим надо взять последние 5 хешей из retro.talks:

/u/e/retro.talks/-5:5

в данном случае смещение отрицательное - значит считаем с конца ну и после двоеточия количество

> и я не понимаю, зачем мне запрашивать кусок эхи не до конца, а посредине.

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

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

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

По идее хеши можно было бы в IDEC протокол добавить для GET /x/c/echo.1/echo.2 которое сейчас возвращает количество сообщений (видимо предполагалось, что сообщения никогда не удаляются). Кто-то вообще пользуется /x/c/... сейчас? Ну или завести новый вызов /x/h/... для возврата списка с хешами списков хешей...

> при запросе /u/e/ с ключом ?sf=хэш он при запросе будет выдавать только хэши после указанного

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

Действительно:

a45cdfa3 (user            2014-04-01 19:19:03 +1100  9) @route('/list.txt')
a45cdfa3 (user            2014-04-01 19:19:03 +1100 10) def list_txt():
a45cdfa3 (user            2014-04-01 19:19:03 +1100 11)     response.set_header ('content-type','text/plain; charset=utf-8')
08c516db (user            2014-04-06 00:06:51 +1100 12)     lst = api.load_echo(False)[1:]
08c516db (user            2014-04-06 00:06:51 +1100 13)     if request.query.n:
08c516db (user            2014-04-06 00:06:51 +1100 14)         return '\n'.join([t[0] for t in lst])
08c516db (user            2014-04-06 00:06:51 +1100 15)     else:
08c516db (user            2014-04-06 00:06:51 +1100 16)         return '\n'.join(['%s:%s:%s' % t for t in lst])
08c516db (user            2014-04-06 00:06:51 +1100 17) 

да - хэш надёжнее, но действительно придётся хранить хеши для каждого узла

вобчем я наверное сделаю у себя вызов GET /x/h/echo.1/echo.2 по аналогии с GET /x/c/echo.1/echo.2

ну и GET /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

> Вообще не понимаю, можно какой-то конкретный пример.

Например ZX Spectrum с сетевой карточкой Spectranet - у этого компа 48КБ ОЗУ только, но т.к. Spectranet использует бейсик (который в ПЗУ прошит в первых 16КБ) у которого есть свои переменные и ещё экран занимает 6912 байт ОЗУ т.е. под буфера останется 32КБ или даже меньше...

> у меня и постраничного вида нет

ну может у кого-то есть, ну или будет ;)

> Эх, лучше бы поддержали POST /u/m, тогда не пришлось бы по куче мелких запросов при перефетче делать.

это тоже можно

ok - попробую для начала list.txt?h=1

кстати у меня апач - у него тоже ограничение на 256 символов в урле?

гугол говорит 8192

> зачем тебе там список сообщений, если ты там и одно сообщение не отобразишь? :)

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

> для таких вещей вообще абсолютно кастомные гейты надо делать, а не стандартные средства

если IDEC уже имеет все средства как часть стандарта, то зачем для него городить кастомные гейты?...

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

https://tgistation.ru/echo/subj/8/%D0%9F%D1%80%D0%B5%D0%B4%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D1%8F%20%D0%B8%D0%BB%D0%B8%20%22%D0%9A%D0%B0%D0%BA%20%D0%BD%D0%B0%D0%BC%20%D0%BE%D0%B1%D1%83%D1%81%D1%82%D1%80%D0%BE%D0%B8%D1%82%D1%8C%20idec%3F%22/

А куда делся ake кстати? Его сайт http://gears.headake.win/idec/ui2/ тоже пропал где-то в 2022 году:

https://web.archive.org/web/20220120232845/http://gears.headake.win/idec/ui2/

Там у него была историческая эха ii.14 которой похоже больше нигде нету :(

https://web.archive.org/web/20211023211000/http://gears.headake.win/idec/ui2/channel/ii.14/

> Сначала научи их utf8 :)

А я уже - ещё в декабре 2021 :)

https://www.youtube.com/live/p20rd0bqZTs

неа

Я с таверны её беру

Чото тормозит она страшно последнее время - чем дальше, тем страшнее...

видо :)

[forwarded from idec.test]

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

[forwarded from idec.test]

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

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

[forwarded from idec.test]

Да - ближе к концу лога access.log твой юзер-агент curl/7.54.1 сменился на tii/current

[forwarded from idec.test]

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

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

[forwarded from idec.test]

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

[forwarded from idec.test]

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

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

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

[forwarded from idec.test]

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

[forwarded from idec.test]

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

[forwarded from idec.test]

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

[forwarded from idec.test]

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

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

[forwarded from idec.test]

Проверил каждое сообщение - там где есть repto оно ведет куда надо - на новую копию сообщения

Есть только одно сообщение с перепутанными полями (где сабж shaos) - его наверное можно заблеклистить

Как и одно с абракадаброй вместо текста…

Номер может остаться тот же когда скажем добавили 1 сообщение, но в то же время заблеклистили 1 из середины - поэтому идея с хешами списков хешей мне кажется более работоспособной

Количество в общем случае не показатель - сообщения могут не только добавляться, но и удаляться

> На этот счёт спецификация явно говорит, что счётчик может только увеличиваться.

Но на практике у всех разные номера для тех же самых эх...

Заблеклистил несколько сообщений, которые 100% тестовые либо кривые

> Но вред файлэх в чём?

1. Там передаётся нетекстовая информация т.е. через терминал уже не будет работать
2. Функционально файл из файлэхи это просто забирание файла по HTTP - зачем городить лишние абстракции?
3. Сейчас (на таверне) оно используется в основном только для раздачи порнухи и пиратских книг...

Сообщение можно не только заблеклистить, но и удалить

в ii-php уменьшается

технически это немножко сложно его неуменьшать

это если хранить по простому в файлах

а если в SQL то там можно просто max(index) выдавать и он всегда будет расти (но фактически сообщений будет меньше)

Там ещё идея с подменой (amend) сообщений выглядит интересной - идеологически верная альиернатива редактированию старых мессаг...

хотя не - max(index) не будет работать т.к. индекс общий на все эхи
видимо надо запрещать удалять сообщения физически...

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

> Это было в 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?

Мне нравится идея, что у каждого свой суверенный блеклист :)

Лучше когда все фетчат всех - и надежнее, и быстрее сообщения доходят :)