Re: Полуневдимые эхи
Ответ на сообщение
Тоже самое можно сказать и про IDEC сейчас :)
shaos to Reprise (2024-10-24 12:50:05)
[ссылка]
> Для того, чтобы её не было, нужно писать дополнительный код, который по идее вообще вредный, так как удобную фишку убирает….Ну например можно выкинуть «вообще вредный» код файлэх, который сейчас чуть ли не половину всего кода ii-php занимает :)
shaos>> И кстати зачем родили IDEC если ii был такой уютненький и самодостаточный? ;)
revoltech> Да вот не знаю, кстати, мне пока что только расширение с list.txt полезным показалось.Там есть полезная вещь, возможность забирать не все сообщения, а только часть. Например, последние n сообщений. Это позволяет делать фетчинг который не гоняет по интернету всегда полный индекс. Очень сильно снижает количество трафика.
> Очень сильно снижает количество трафика.Это да :)
shaos> При наличии групп эх наверное можно таки дать возможность пользователям (с высокой кармой?) создавать новые публичные эхи в группе unsorted - эдакий crowd sourcing получится, но по умолчанию такие эхи должны будут быть скрыты от веба (хоть и будут перечислены в list.txt)..,Мой посыл состоял в том числе и в посыле веба нафиг. А вот карма и прочие соцрейтинги пусть там, в вебе, и остаются. Если мои сообщения из веб-зеркал видны не будут, я не сильно расстроюсь.
hugeping> Там есть полезная вещь, возможность забирать не все сообщения, а только часть. Например, последние n сообщений. Это позволяет делать фетчинг который не гоняет по интернету всегда полный индекс. Очень сильно снижает количество трафика.Длина ID сообщения — 21 байт (20 на сам ID и один на перевод строки). Это погоды не делает. Определить, какие айдишники ещё не сфетчены, можно и на клиенте. Погоду делает то, что этих самых айдишников в GET /u/m можно поместить всего 12 штук, а дальше твой (вроде бы, не помню уже) нжинкс начнёт ругаться на слишком длинную строку запроса.
shaos> Это да :)Так всё-таки есть стандартный и поддерживаемый вариант, чтобы полный перефетч эхи делался не кучей мелких запросов по 12 айдишников из-за ограничений хттпшного гета на сервере, а чем-то более вменяемым? Или нет? В доках ничего, кроме GET /u/m, по этому поводу не нарыл.
revoltech> Длина ID сообщения — 21 байт (20 на сам ID и один на перевод строки). Это погоды не делает.Почему не делает? Если каждые 5 минут делать фетч из эх, которые содержат по 10 тысяч сообщений, то как раз делает. Конечно, по современным меркам ~60мб в сутки на 10000 сообщений это вроде бы мелочи, но... Как-то меня такое не вдохновляет. Допустим, сообщений на ноде не 10тыс а 100тыс... Почему нет?
revoltech> В результате при фетче с нуля приходится разбивать каждый список на группы по 12 и выгребать сообщения отдельными запросами. А это не оптимально ни разу.
revoltech> Теперь понятнее?Мне то понятнее, поэтому я и говорю - посмотри как сделано в ii-go. Там быстрый многопоточный фетчер.
revoltech> Так всё-таки есть стандартный и поддерживаемый вариант, чтобы полный перефетч эхи делался не кучей мелких запросовНет. Несколько потоков решают проблему быстрого фетча. А слайсы решают проблему больших индексов.
> Да вот не знаю, кстати, мне пока что только расширение с list.txt полезным показалось.а что за расширение list.txt? не слышал. щас у себя посмотрел, el поддерживает ключи ?h=, ?n=, и ?el= :) сидел соображал. что к чему. не сообразил.
> а что за расширение list.txt?Видимо имелось ввиду что
> я не знаю как запросить последние n сообщенийдопустим надо взять последние 5 хешей из retro.talks:
> и я не понимаю, зачем мне запрашивать кусок эхи не до конца, а посредине.например для ретроклиентов, которые по собственной ограниченности не могут принять многомегабайтный список хешей в один присест - идём кусочками от начала до конца
> Количество сообщений я считаю ненадёжным источником, можно удалить 1 и жобавить 1 и эха вроде не изменится.по идее "жобавляется" всегда в конец, а из середины только удаляется (блеклистается) и если брать частями, то наверное надо брать с перехлёстом на 1, чтобы точно ничего не удалилось на границах блоков пока ты их вычитываешь...
> при запросе /u/e/ с ключом ?sf=хэш он при запросе будет выдавать только хэши после указанногоэто кстати может не работать правильно, если узел берёт эху с разных нод - порядок мессаджей на разных нодах может немного отличаться в зависимости от того в каком порядке туда ответы приходили - поэтому просить N последних логичнее нежели просить после хэша XXX...
> например для ретроклиентов, которые по собственной ограниченности не могут принять многомегабайтный список хешей в один присест - идём кусочками от начала до концаВообще не понимаю, можно какой-то конкретный пример. Зачем брать кусками список? И мегабайт хэшей - это 49000 сообщений. Вообще не могу представить юзкейс.
> допустим надо взять последние 5 хешей из retro.talks:я всё равно не могу понять, зачем это может быть нужно кроме юзкейса "запросить n последних сообщений". Я в слайсах не разбираюсь, там вечно массив 20 может быть или 19, или 20, или 21, у меня и постраничного вида нет, потому что у меня и реверс и разбирать это я с ума сойду. Вот это я сделать не смогу, мне слишком нудно разбираться. Достаточно было одного крайнего случая "н последних сообщений", это гораздо проще кодить и на клиенте, и на сервере. Мой lim прозрачен для вообще любых клиентов, какие существовали в истории, если кто-то не хочет тянуть 49000 файлов. А по факту в txt клиенте у меня уже ограничение на запрос только 100 последних мессаг. Средств для больших эх никогда не задумывалось потому что изначально, и это была часть концепции, не должно было быть больших эх.
> /u/e/retro.talks/-5:5
> в данном случае смещение отрицательное - значит считаем с конца ну и после двоеточия количество
> по идее "жобавляется" всегда в конец, а из середины только удаляется (блеклистается) и если брать частями, то наверное надо брать с перехлёстом на 1, чтобы точно ничего не удалилось на границах блоков пока ты их вычитываешь...ну если бы я делал фетчер, я бы ещё штук 5 сверху проверял, на всякий случай. и раз в день полная проверка списка.
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)
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, тогда не пришлось бы по куче мелких запросов при перефетче делать.
> Вообще не понимаю, можно какой-то конкретный пример.Например ZX Spectrum с сетевой карточкой Spectranet - у этого компа 48КБ ОЗУ только, но т.к. Spectranet использует бейсик (который в ПЗУ прошит в первых 16КБ) у которого есть свои переменные и ещё экран занимает 6912 байт ОЗУ т.е. под буфера останется 32КБ или даже меньше...
> у меня и постраничного вида нетну может у кого-то есть, ну или будет ;)