> я не знаю как запросить последние 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...

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

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

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

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

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

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

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

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

у меня это так было сделано

https://github.com/gk11-ru/ii-elp/blob/master/run.py#L24

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

hugeping> Нет.

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

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

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

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

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

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

shaos> это тоже можно

Это было бы здорово. С любым ударением на этом слове.

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

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

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

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

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

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

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

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

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

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

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

У меня в фетчере то ли по 20 то ли по 40. Вся текущая сеть выкачивается довольно быстро.

На мобильном интернете

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

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

Кстати вопрос про POST в /u/m периодически поднимался, например вот тут 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/ href="http://gears.headake.win/idec/ui2/">http://gears.headake.win/idec/ui2/

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

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

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

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

Один запрос на тысячи сообщений. И если что то не докачается, качай всё заново. Поэтому секциями и качается.

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

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

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

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

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

7 пункт используется в elp. Жалею что не включил сразу.

Она же есть в аликорновских архивах вроде?

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

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

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

Сабж. Тяну с shaos, не обновлялась с 16 октября.

неа

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

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

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

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

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

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

Надо найти хоть кого то у кого есть архивы

Я кликнул difrex a на лоре но он не ответил

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

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

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

У меня станция spline сейчас вообще не открывается

Открысля. Да, эхи с ботами не обновляются.

Узнал об эхе test. Нифига вы там беседы беседуете, может конвертнуть избранное в talks для истории?

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

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 что?

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

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

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

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

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

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

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

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

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

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

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

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

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 кбайт - сожрало

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

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

Тестируем многострочный пост, как я бы его обычно писал в виме до того, как
допилю 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]

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

[forwarded from idec.test]

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

[forwarded from idec.test]

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

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

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

[forwarded from idec.test]

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

[forwarded from idec.test]

@>1C5< 87 3@0D8G5A:>3> :;85=B0 GB>-B> >B?@028BL

[forwarded from idec.test]

А щас?

[forwarded from idec.test]

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

[forwarded from idec.test]

Пишу сам себе.
Ага.

[forwarded from idec.test]

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

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

[forwarded from idec.test]

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

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

[forwarded from idec.test]

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

[forwarded from idec.test]

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

[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> Ну и есть всякие плюшки типа минимальной гарантии доставки

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

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

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

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

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

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

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

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

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

я тоже не фетчу idec.test и не собираюсь, поэтому диалог перетащил сюда

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

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

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

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

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

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

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

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

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

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

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

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

я не нашёл проблем с repto, сообщения корректные

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

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

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