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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

hugeping> Нет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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) 

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

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

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

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

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

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

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

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

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

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

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

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

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

Это всегда было

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

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

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

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

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

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

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

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

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

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

GET /list.txt

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

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

Я думал, ты про аватарки девочек, которые были в 2014 году. Надо попробовать их на py3 портировать.

Ага, это Оля. Просто я когда возобновлял станцию, взял первую попавшуюся версию, а она с Олей, я и оставил. При переезде на picnic тоже оставлю.

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

Тока оно неверно работает, надо поменять

Точнее наоборот, сообразил :)

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

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