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


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

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

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

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

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

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

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

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

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

aCdkdL... . ОТВЕТИТЬ



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

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

90NVGj... . ОТВЕТИТЬ



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

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

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

Zk4mNN... . ОТВЕТИТЬ



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

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

bCUznG... . ОТВЕТИТЬ



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

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

Вообще не понимаю, можно какой-то конкретный пример. Зачем брать кусками список? И мегабайт хэшей - это 49000 сообщений. Вообще не могу представить юзкейс.

> допустим надо взять последние 5 хешей из retro.talks:
> /u/e/retro.talks/-5:5
> в данном случае смещение отрицательное - значит считаем с конца ну и после двоеточия количество

я всё равно не могу понять, зачем это может быть нужно кроме юзкейса "запросить n последних сообщений". Я в слайсах не разбираюсь, там вечно массив 20 может быть или 19, или 20, или 21, у меня и постраничного вида нет, потому что у меня и реверс и разбирать это я с ума сойду. Вот это я сделать не смогу, мне слишком нудно разбираться. Достаточно было одного крайнего случая "н последних сообщений", это гораздо проще кодить и на клиенте, и на сервере. Мой lim прозрачен для вообще любых клиентов, какие существовали в истории, если кто-то не хочет тянуть 49000 файлов. А по факту в txt клиенте у меня уже ограничение на запрос только 100 последних мессаг. Средств для больших эх никогда не задумывалось потому что изначально, и это была часть концепции, не должно было быть больших эх.

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

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

KqmUkC... . ОТВЕТИТЬ



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

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

7IJgBK... . ОТВЕТИТЬ





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

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

====
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)
====


M36xgS... . ОТВЕТИТЬ



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

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

вобчем я наверное сделаю у себя вызов 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
====


7aROsE... . ОТВЕТИТЬ



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

shaos> ну и GET /list.txt?h=1 заодно тоже можно поддержать ;)

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

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

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



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

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

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

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

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

Azrimy... . ОТВЕТИТЬ



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

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

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

eIrJj4... . ОТВЕТИТЬ





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

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

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

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

ps. блин, опять потерялся текст про спектрум в коробке из под обуви, интересно в какую эху я его запульнул в итоге... в рухуморе14 нет

namIvk... . ОТВЕТИТЬ



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

hugeping> Нет.

Вполне достаточный ответ.

hugeping> А слайсы решают проблему больших индексов.

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

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

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

w1w2Mv... . ОТВЕТИТЬ









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

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

Да, в теории 389 айдишников туда поместятся. Всё равно маловато, но лучше, чем по 12 группировать.

Может, сделаю в stations.txt напротив каждой урлы поле, которое указывает максимальное количество адишников. Мол, если не знаем, ставим 12.

TUUvfJ... . ОТВЕТИТЬ



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

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

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

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

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

bcGCVv... . ОТВЕТИТЬ



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

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

Без гейта ты нормально не отобразишь ничего ни на zx spectrum ни на msdos, ни на atari st. Сначала научи их utf8 :)

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

eQvqj5... . ОТВЕТИТЬ







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

Операция атомарна, поэтому надо чтобы в случае чего она была проведена без сбоев, а то заново придётся качать

За 10 лет не помню проблем с текущим фетчем

waPdSq... . ОТВЕТИТЬ



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



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

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

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

С тем же успехом можно на Gemini/Spartan перелезть полностью — там длина запроса 2048 символами ограничивается, если не ошибаюсь. В Nex и такого ограничения нет.

4KgeB0... . ОТВЕТИТЬ



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

Кросспостинг был изначально, но я от него сразу отказался, он создаёт больше проблем, чем решает. Он тут не нужен

NXpuLv... . ОТВЕТИТЬ













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

> С тем же успехом можно на Gemini/Spartan перелезть полностью — там длина запроса 2048 символами ограничивается, если не ошибаюсь. В Nex и такого ограничения нет.

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

Сегментирование запросов было введено специально. И я не вижу проблемы, я щас всю rulinux14 скачал за несколько секунд.

Fb8hAH... . ОТВЕТИТЬ







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

ahamai> По хттп можно качать хоть с дискеты и вообще отовсюду, он есть везде.

А для некса с гофером вообще ничего, кроме нетката/телнета (голого TCP), не нужно.

ahamai> Сегментирование запросов было введено специально.

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

ahamai> И я не вижу проблемы, я щас всю rulinux14 скачал за несколько секунд.

Сколько сообщений можно выкачать за один запрос у тебя на станции?

Noq1sm... . ОТВЕТИТЬ







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

Идея в том, что есть и библиотеки, и средсва в системе, и можно с плмощью wget, cat и такой то матери в три строчки собрать простейший клиент.

Лимит на get у меня вроде тоже 8 кб

1o2JLN... . ОТВЕТИТЬ













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

ahamai> Идея в том, что есть и библиотеки, и средсва в системе, и можно с плмощью wget, cat и такой то матери в три строчки собрать простейший клиент.

Намёк был на то, что есть транспорты ещё проще, чем HTTP. Например, Nex/NPS можно вообще описать парой коротких предложений:

1. Скачивание (Nex): отправляем путь и LF на TCP-порт 1900, забираем данные.
2. Постинг (NPS): отправляем путь и LF, опционально строку авторизации и LF, сами данные, LF, точку (.) и LF на TCP-порт 1915, забираем ответ.

Всё, это оба протокола. Дальше в Nex расписано, что рекомендуется делать на клиенте, если путь заканчивается на /, но к ii это уже можно не применять. Вместо LF можно использовать CRLF, как минимум существующие сервера это понимают.

Суть именно в простоте, даже на оф.сайте указано сверху, как через nc выгрести Nex-ресурс:

echo nps/info/form.txt | nc nightfall.city 1900 | less

С гофером, кстати, точно так же, только порт по умолчанию 70. Но нет, давайте городить огород с ненужными для ii HTTP-хедерами, лимитами на гет-запросы и контент-тайпами.

Если что, не осуждаю существующие подходы, просто не понимаю, почему бы опционально не сделать ещё проще.

ahamai> Лимит на get у меня вроде тоже 8 кб

Это типа «640 кб хватит всем»? :D Ну ладно, поставил тоже 389 на запрос. Как-нибудь попробую перефетч. А у остальных как? У пинга понятно, нжинкс и 12 сообщений на запрос максимум. А у spline-online и tgistation что?

SO0bBc... . ОТВЕТИТЬ



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

revoltech> И там AL написал, что POST /u/m не решает ни одной проблемы. Как же не решает, если решает? Вот вам проблема: куча лишних соединений и метаданных

Каких метаданных и почему куча соединений? Если ты работаешь последовательно - то это несколько подряд идущих get запросов, а не куча параллельных соединений. Если же ты хочешь скорости, то да - потоки. Но это вообще говоря две независимые вещи. Например, запуск отдельных фетчеров на каждый узел. И да, многопоточность не связана с наличием свободных процессоров. Там нагрузки практически нет, вопрос не в утилизации мощности вычислительной, а в "съедании" времени ожидания TCP.

8sAzuc... . ОТВЕТИТЬ



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

revoltech> У пинга понятно, нжинкс и 12 сообщений на запрос максимум.

У меня нет веб сервера. Насчёт 12 сообщений, интересный вопрос. Это проверено? Я посмотрю, может быть это можно настроить в go библиотеке.

zDTrsh... . ОТВЕТИТЬ



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

revoltech>> У пинга понятно, нжинкс и 12 сообщений на запрос максимум.

hugeping> У меня нет веб сервера. Насчёт 12 сообщений, интересный вопрос. Это проверено? Я посмотрю, может быть это можно настроить в go библиотеке.

В общем, откуда инфа про 12? Запрос ввёл сейчас раза в два больше - не вижу ограничений. Или это опять, поэтическое преувеличение?

z5oeWQ... . ОТВЕТИТЬ



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

hugeping> У меня нет веб сервера. Насчёт 12 сообщений, интересный вопрос. Это проверено? Я посмотрю, может быть это можно настроить в go библиотеке.

А, значит, с tgi перепутал. Пардон. Изначально тестил на обоих.

OE0R5G... . ОТВЕТИТЬ



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

hugeping> Каких метаданных и почему куча соединений?

Даже если отбросить всю низкоуровневую тряхомудию с установкой TLS-соединения и проверкой сертификатов при HTTPS, каждый HTTP-запрос — это статусы, заголовки Accept, Content-Type, Content-Encoding и т.д. Тут, как ни крути, оверхед будет существенным при большом количестве мелких запросов. Поэтому тело запроса укрупнять смысл имеет в любом случае.

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

8moYNF... . ОТВЕТИТЬ



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

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

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

80dk50... . ОТВЕТИТЬ



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

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

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

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

pfhpzp... . ОТВЕТИТЬ





\/ . ahamai to All @ idec.test 25/10/24 10:37

shaos, почему с тебя idec.test не фетчится?

ps. Ценность маленьких запросов понимаешь, когда фетчишь с spline :)

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



\/ . revoltech to All @ Мея видо? 23/10/24 06:13

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

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

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

[forwarded from idec.test]

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





\/ . Andrew Lobanov to revoltech @ Re: Мея видо? 23/10/24 08:43

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

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

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

[forwarded from idec.test]

1m02iM... . ОТВЕТИТЬ





\/ . revoltech to Re: Мея видо? @ shaos 23/10/24 10:24

Да, так задумано, если о пустой строке между абзацами речь.

[forwarded from idec.test]

ScavLd... . ОТВЕТИТЬ





\/ . Andrew Lobanov to shaos @ Re: Мея видо? 23/10/24 11:01

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

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

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

[forwarded from idec.test]

PxALqf... . ОТВЕТИТЬ



\/ . revoltech to Andrew Lobanov @ Re: Мея видо? 23/10/24 11:14

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

[forwarded from idec.test]

LnZfFn... . ОТВЕТИТЬ







\/ . revoltech to All @ Re: GUI test номер два 23/10/24 11:56

Во, разобрался. Короче, перед base64 надо явно тиклю перегонять в UTF-8, даже если ввод уже в оном.

[forwarded from idec.test]

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





\/ . revoltech to All @ ii и user agent 23/10/24 14:51

Теперь, по идее, мой клиент уже должен светить агента tii/current.

А какие юзерагенты имеют другие клиенты вроде того же Caesium? Что-то своё или дефолт какой-нибудь?

[forwarded from idec.test]

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





\/ . shaos to revoltech @ Re: ii и user agent 23/10/24 16:19

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

[forwarded from idec.test]

Ul4fIW... . ОТВЕТИТЬ



\/ . revoltech to All @ Некоторые новости 23/10/24 18:25

Мигрировал клиента на sqlite, так что если будет ещё один большой фетч, не удивляйтесь.

[forwarded from idec.test]

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



\/ . Andrew Lobanov to revoltech @ Re: Мея видо? 24/10/24 05:03

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

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

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

[forwarded from idec.test]

MCcwOx... . ОТВЕТИТЬ



\/ . revoltech to Andrew Lobanov @ Re: Мея видо? 24/10/24 05:47

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

[forwarded from idec.test]

dm0W91... . ОТВЕТИТЬ



\/ . shaos to revoltech @ Re: Мея видо? 24/10/24 05:52

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

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

[forwarded from idec.test]

v3r8gG... . ОТВЕТИТЬ



\/ . revoltech to revoltech @ Re: Мея видо? 24/10/24 05:55

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

[forwarded from idec.test]

hmuERo... . ОТВЕТИТЬ



\/ . revoltech to shaos @ Re: Мея видо? 24/10/24 06:04

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

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

[forwarded from idec.test]

vGzdok... . ОТВЕТИТЬ





\/ . revoltech to shaos @ Re: Мея видо? 24/10/24 07:12

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

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

[forwarded from idec.test]

Gz7Tqh... . ОТВЕТИТЬ



\/ . shaos to revoltech @ Re: Мея видо? 24/10/24 07:18

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

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

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

[forwarded from idec.test]

yecmBG... . ОТВЕТИТЬ



\/ . Andrew Lobanov to revoltech @ Re: Мея видо? 24/10/24 08:27

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

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

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

[forwarded from idec.test]

INe7kx... . ОТВЕТИТЬ



\/ . Andrew Lobanov to shaos @ Re: Мея видо? 24/10/24 08:27

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

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

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

[forwarded from idec.test]

ZocLzg... . ОТВЕТИТЬ



\/ . shaos to Andrew Lobanov @ Re: Мея видо? 24/10/24 11:18

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

[forwarded from idec.test]

3mMNAM... . ОТВЕТИТЬ



\/ . Andrew Lobanov to shaos @ Re: Мея видо? 24/10/24 11:55

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

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

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

[forwarded from idec.test]

niirCt... . ОТВЕТИТЬ



\/ . revoltech to Andrew Lobanov @ Re: Мея видо? 24/10/24 11:32

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

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

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

[forwarded from idec.test]

7HbOCe... . ОТВЕТИТЬ



\/ . revoltech to shaos @ Re: Мея видо? 24/10/24 11:34

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

[forwarded from idec.test]

TzWmpp... . ОТВЕТИТЬ



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

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

[forwarded from idec.test]

DiUS18... . ОТВЕТИТЬ



\/ . shaos to revoltech @ Re: Мея видо? 24/10/24 12:27

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

[forwarded from idec.test]

kBmnz4... . ОТВЕТИТЬ



\/ . shaos to Andrew Lobanov @ Re: Мея видо? 24/10/24 12:31

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

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

[forwarded from idec.test]

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





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

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

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

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

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

udAO2u... . ОТВЕТИТЬ



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

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

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

YxUZjS... . ОТВЕТИТЬ



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

я не понимаю, зачем. если что-то где-то сглючит, качать придётся всё заново. поэтому и сделали разбивку на мелкие секции, скачал/записал, скачал/записал. но попробуй, я понятия не имею.

URGnpI... . ОТВЕТИТЬ



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

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

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

BdEDQ9... . ОТВЕТИТЬ



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

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

1IzLH5... . ОТВЕТИТЬ





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

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

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

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

EAcv5l... . ОТВЕТИТЬ



\/ . hugeping to hugeping @ Re: Мея видо? 25/10/24 11:23

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

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

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

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

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

W6gyOe... . ОТВЕТИТЬ



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

в смысле? я проверял repto, вроде всё работало.

shaos, проверь repto? если кривые, то вычищаем тему

mmJM8t... . ОТВЕТИТЬ



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

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

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

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





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

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

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

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

knVHGT... . ОТВЕТИТЬ


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