> tgi же неоднократно просил считать владелец станцией экспериментов и не фетчиться с неё.Ну может кого и просил, но мы с ним в сентябре 2022 года по е-мейлу договорились взаимно фетчить idec.talks и zx.spectrum, а потом я ещё bot.habr.rss у него начал забирать.
shaos> Лучше написать не больше 380 т.к. вебсервер может такое не пережуватьНу я о том же, можно сказать, что 380 — максимум, который нужно поддерживать, а дальше уже на усмотрение владельца сервера.
shaos> И наверное надо метод POST добавить (я у себя добавлю)Только за, но здесь почему-то нашлись принципиальные противники этой идеи.
shaos> Рекомендовать 32 т.к. оно вообще не через http-сервер может идти, а через самописный (кстати bottle.py какое ограничение имеет?)Да у самописных вообще ограничений нет обычно.
AL>> Пинать сисопа своего аплинка. Потому что такие короткие урлы это издевательство.10+ лет качаем по 40. Полёт нормальный. Зачем выдумывать себе трудности? Чтобы героически их преодолевать?
revoltech> Хорошо. Какие — не издевательство? Сколько айдишников скачивать по умолчанию? Где проходит граница между «слишком жирно» и «пора пинать сисопа»?
revoltech> Может, в стандарте хотя бы рекомендованное число указать в таком случае? Опытным путём вот выяснилось, что апачу 389 айдишников можно скормить в /u/m на дефолтных настройках. А на spline-online сколько, например?Настройки веб-сервера выходят за рамки стандарта.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
hugeping>> It is RECOMMENDED that all senders and recipients support, at a minimum, URIs with lengths of 8000 octets in protocol elements.Это уже прописано в стандарте. Только почему это должно быть прописано в стандарте IDEC?
revoltech> Так, может, тогда и в стандарте прописать |(8000 - 5) / 21| = 380 айдишников рекомендованным максимумом для отдачи через /u/m?
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
hugeping>> Всё-таки, это не аксиома. Тут мы зависим от внешнего фактора.Хорошо. Я укажу в стандарте 40. Все, кто качает больше или предоставляют меньше, не соблюдают стандарт.
revoltech> Не аксиома, но вполне разумное значение по умолчанию. Сисопа проще пнуть на документальном уровне и пусть объясняет, почему приём 380 айдишников в /u/m для него проблема.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
shaos>> И наверное надо метод POST добавить (я у себя добавлю)Эта идея решает примерно - проблем. Так зачем?
revoltech> Только за, но здесь почему-то нашлись принципиальные противники этой идеи.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
> Например, в данном случае, в один запрос запиханы разные лимиты слайсов для разных эх. Зачем?Так это была изначальная идея - для экономии трафика. я всегда думал, что оно именно так и сделано, там 100 rss сообщений за час их и забрали, там 1 за неделю. а так это какая-то полумера, ни туда ни сюда.
> Потом, Рома трясёт своим ?sf=hash - как замену слайсов.Приехали. Я не использую ?sf. Я не собираюсь использовать ?sf. Оно создано ровно для одного случая, работы в условиях медленного интернета. Для чего, как заявлялось, и делался idec. И, в отличие от idec, он делает ровно то, что от него просят, даёт одним запросом ровно то, что нужно, минимальный объём сообщений.
> На самом деле этот sf=hash при своей красоте, всё-таки, хуже слайсов. Во первых, даже с хешем надо делать запрос внахлёст с запасом (не забываем про то, что порядок сообщений на ноде может не совпадать с нашим)Не надо так делать. В 99% случаев запрос вернёт ровно то, что от него хотят. В остальных случаях, скорее всего, поможет только полный фетч.
> и нам все равно придётся самим на своей станции находить n сообщение от конца в эхе и брать затем его хеш чтобы сформировать запрос. Те же слайсы, вид сбоку.Только все эхи опрашиваются одним запросом, и с нужным количеством сообщений.
> Ну и во-вторых, sf решает одну конкретную задачу, а слайсы - универсальны. Слайсы делают возможным адаптивный фетч и онлайн просмотр.То, что называется слайсы, у меня называется lim. Сделано одной строчкой кода. Совместимо вообще со всем, не ломает /u/e/, и даже клиенты, которые понятия не имеют о lim, могут им пользоваться.
> В общем, попытки решить какие-то несуществующие проблемы и навязать какие-то свои оценки. Чего я боялся, то и происходит. Лебедь рак и щука.Проблема была в проектировании. Некорректном дизайне. В сломе того, что просто работало и было простым, как три копейки, ради решения несуществующих проблем и каких-то непонятных смен стандарта, которые ничего не дают, кроме экономии трафика, которой тоже нет, потому что у тебя либо постоянные новые запросы, новые коннекции, новые строчки в логе сервера и так далее, да там tcp фреймы больше сожрут чем трафика сэкономится :)
AL> 10+ лет качаем по 40. Полёт нормальный.Ну а мне откуда было это знать? Нигде о 40 не было написано. А tgi уже на 13 посылает куда подальше, например.
AL> Хорошо. Я укажу в стандарте 40. Все, кто качает больше или предоставляют меньше, не соблюдают стандарт.Ну вот так бы сразу.
> Только за, но здесь почему-то нашлись принципиальные противники этой идеи.потому что у больших запросов куча проблем и никакого смысла. поэтому в своё время и перешли от них к маленьким. я вообще не понял, какая проблема решается, первоначальный фетч всей текущей сети занимает небольшое время, большой запрос принципиально ничего не изменит. но нагрузка на серверы растёт, однопоточные серверы вообще поставит колом. я не говорю про проблемы обрыва связи. чанками разумного размера качать лучше, чем целым. оптимальным числом эмперическим путём было выбрано 40.
ahamai> если ты предоставишь бенчмарки, что выгрузка всех сообщений единым блоком хотя бы в 2 раза быстрее, чем чанками по 20 сообщений, тогда это будет интересно. тогда мож и /get вернётся.Это зависит от местоположения клиента и ноды. В стерильных тестовых условиях, может, и не вдвое быстрее будет. А вот в реальных время установки TCP/TLS-соединения тоже существенно добавляет к общей картине. Могу на днях замерять перефетч с shaos-а после уменьшения чанка с 389 сообщений до 40. Или с ping после уменьшения с 10000 до 40... Если интересно.
>> Ну и во-вторых, sf решает одну конкретную задачу, а слайсы - универсальны. Слайсы делают возможным адаптивный фетч и онлайн просмотр.Только твой lim решает совершенно другую задачу. Ты попробуй прочитать хотя бы черновик стандарта. То, что ты видишь единственное применение слайсам, не означает, что существует только оно.
ahamai> То, что называется слайсы, у меня называется lim. Сделано одной строчкой кода. Совместимо вообще со всем, не ломает /u/e/, и даже клиенты, которые понятия не имеют о lim, могут им пользоваться.
ahamai> Адаптивный фетчинг это оверинжиниринг, программирование ради программирования, он вообще не даёт гарантий, в станциях где нет формальных эх а сортировка идёт по timestamp, могут быть вкинуты старые сообщения и такой фетчинг их не увидит. В нормальных условиях я вообще не вижу проблем гонять полные эхи, ибо только они дают полную гарантию. Для экономии трафка можно использовать ?h, его использование в гейтовании с shaos сократило дневной трафик с 12 мб до 2.Если узел отдаёт индекс с сортировкой по времени сообщений, то его надо снимать с фетчинга, потому что это как минимум хулиганство. Как отдача полного индекса решает проблему выкинутых сообщений вообще непонятно.
>> В общем, попытки решить какие-то несуществующие проблемы и навязать какие-то свои оценки. Чего я боялся, то и происходит. Лебедь рак и щука.Кто о чём, а Рома снова о том, что idec это не ii. Потому и не ii, что ii имел фундаментальные проблемы в дизайне.
ahamai> Проблема была в проектировании. Некорректном дизайне. В сломе того, что просто работало и было простым, как три копейки, ради решения несуществующих проблем и каких-то непонятных смен стандарта, которые ничего не дают, кроме экономии трафика, которой тоже нет, потому что у тебя либо постоянные новые запросы, новые коннекции, новые строчки в логе сервера и так далее, да там tcp фреймы больше сожрут чем трафика сэкономится :)
ahamai> Забавно, я посмотрел архив старых эх - я постоянно из протокола что-то выкидывал, пока не остались /e /m /u/e /u/m, и всё это не достигло предельной простоты. А щас только что-то добавляют. Да сколько угодно. Но не надо лезть в /u/e.В твой ii никто не лезет. Ты можешь взять хоть ii-0.3 и работать с idec. Но и ты в свою очередь не лезь в idec. Постоянно добавляют, это одни только слайсы. Если у тебя от них пригорает, просто не используй их. Нет, мы будем изобретать несовместимые со стандартом велосипеды.
ahamai> Это база из баз, фейлбек из фейлбеков, он должен быть простым, примитивным, кодиться за три строчки кода на любом языке и быть единой везде.Он никогда не кодился за три строчки даже на петухоне. Я твою референсную реализацию читал.
ahamai> Расширяйте как хотите, но расширяйте отдельные методы, без x/feaures и прочего фиг пойми зачем, может нода работать по новому - запрашиваем, не может - фэлбэчимся на старое.Рома, закопай уже стюардессу. Сабжа не будет. По крайней мере в стандарте. В плане обмена мой черновик останется без изменений. Изменения будут только в сопроводительном тексте для устранения неоднозначностей.
+++ Caesium/0.4 RC1
AL>> 10+ лет качаем по 40. Полёт нормальный.Готовый софт уже делал так. Всё на гитхабе есть - бери и смотри, раз уж начал своё писать.
revoltech> Ну а мне откуда было это знать? Нигде о 40 не было написано. А tgi уже на 13 посылает куда подальше, например.
AL>> Хорошо. Я укажу в стандарте 40. Все, кто качает больше или предоставляют меньше, не соблюдают стандарт.Договорились.
revoltech> Ну вот так бы сразу.
+++ Caesium/0.4 RC1