[#]
Дополнения к стандарту
revoltech(spnet, 4) — revoltech
2024-10-31 05:14:34
Предлагаю ввести общий слайсинг вида «ключ-значение», в котором вместо диапазона можно писать all или же msgid (в таком случае берётся содержимое эхо от него):
/u/e/echo.1/all/echo.2/some_msgid_blablabla/echo.3/-10:10
А ещё предлагаю ввести /u/mc, возвращающий число, чтобы клиент знал максимум сообщений, который нода может ему отдать за один GET-запрос /u/m.
[#]
Re: Дополнения к стандарту
revoltech(spnet, 4) — shaos
2024-10-31 05:48:09
shaos> ну разве что если /x/e/...
Да пофигу, раз упростить алгоритмически всё равно ничего не получится, пусть будет так, как есть. Меня больше про /u/mc вопрос интересует.
[#]
Re: Дополнения к стандарту
shaos(spnet, 2) — revoltech
2024-10-31 05:57:34
насколько длинный урл можно скормить вебсерверу это настройка вебсервера - сама нода может про это и не знать
[#]
Re: Дополнения к стандарту
revoltech(spnet, 4) — shaos
2024-10-31 06:05:06
shaos> насколько длинный урл можно скормить вебсерверу это настройка вебсервера - сама нода может про это и не знать
Но её админ должен об этом знать. И выставить в урлу /u/mc. Иначе при перефетче придётся брутфорсить на стороне клиента: ага, 10000 айдишников — отлуп, 1000 айдишников — отлуп, 500 — отлуп, 389 — норм... Запишем, что в этой станции 389.
[#]
Re: Дополнения к стандарту
shaos(spnet, 2) — revoltech
2024-10-31 06:12:07
> Но её админ должен об этом знать.
Ну я например не знал пока не загуглил :)
Потом пришлось свой анализатор логов переписывать, чтобы строки длинне 8К принимал ;)
[#]
Re: Дополнения к стандарту
hugeping(ping,1) — revoltech
2024-10-31 07:40:58
Я тут несколько дней сдерживаюсь. К тому же, довольно сильно приболел.
Но сдерживаться мне всё тяжелее конечно...
Понимаю, что меня не воспримут, всё-таки напишу.
Подумайте, что за задачи вы решаете?
Например, в данном случае, в один запрос запиханы разные лимиты слайсов для разных эх. Зачем?
Видимо, предполагается что "умный" админ будет настраивать фетч таким образом под станцию, что задаст разные лимиты для эх разной наполненности? Зачем этот ужас? Придумайте, как в реальности вы будете это использовать?
Потом, Рома трясёт своим ?sf=hash - как замену слайсов. На самом деле этот sf=hash при своей красоте, всё-таки, хуже слайсов. Во первых, даже с хешем надо делать запрос внахлёст с запасом (не забываем про то, что порядок сообщений на ноде может не совпадать с нашим) и нам все равно придётся самим на своей станции находить n сообщение от конца в эхе и брать затем его хеш чтобы сформировать запрос. Те же слайсы, вид сбоку. Ну и во-вторых, sf решает одну конкретную задачу, а слайсы - универсальны. Слайсы делают возможным адаптивный фетч и онлайн просмотр.
Потом постоянные намёки на то, что нам нужно обязательно забрать всё одним запросом. Причём, неявно подразумевается что это благая цель которую все разделяют... ЗАЧЕМ?? У меня фетчер вообще забирает по 12 кажется msgid за раз, но он, наверное, самый быстрый из всех реализаций что я видел. Можете скачать ii-go и сделать полное клонирование моей станции и написать, сколько это заняло времени.
Про ограничение на запрос. В лучшем случае в стандарт можно добавить рекомендацию про 8кб "стандарт" запроса, который в большинстве случаев совпадает с фактическим положением дел. Но расширение, которое будет показывать этот параметр, который вообще говоря доступен только веб серверу? Сами же простоту и элегантность хотите, нет? По 16 msgid забирать чистоплюство не позволяет? Значит, страдайте! :)
В общем, попытки решить какие-то несуществующие проблемы и навязать какие-то свои оценки. Чего я боялся, то и происходит. Лебедь рак и щука.
Моё мнение -- надо замораживать вариант драфта Андрея. А дальше, пилить альтернативный стандарт - если он будет хорош - ну значит его поддержит. Кто-то. Но в таком хаосе и горячке я точно не участник. Мне не нравится русло в которое все свернуло. Но это - неизбежно. Поэтому коммьюнити не будет. Никогда.
[#]
Re: Дополнения к стандарту
Andrew Lobanov(tavern,1) — revoltech
2024-10-31 07:52:21
revoltech> Предлагаю ввести общий слайсинг вида «ключ-значение», в котором вместо диапазона можно писать all или же msgid (в таком случае берётся содержимое эхо от него):
revoltech> /u/e/echo.1/all/echo.2/some_msgid_blablabla/echo.3/-10:10
Зачем? Усложнение ради усложнения? Так IDEC не про это, а про дубовую простоту.
[#]
Re: Дополнения к стандарту
Andrew Lobanov(tavern,1) — revoltech
2024-10-31 07:52:21
shaos>> ну разве что если /x/e/...
revoltech> Да пофигу, раз упростить алгоритмически всё равно ничего не получится, пусть будет так, как есть. Меня больше про /u/mc вопрос интересует.
Не вижу в нём смысла.
[#]
Re: Дополнения к стандарту
Andrew Lobanov(tavern,1) — revoltech
2024-10-31 07:52:21
shaos>> насколько длинный урл можно скормить вебсерверу это настройка вебсервера - сама нода может про это и не знать
revoltech> Но её админ должен об этом знать. И выставить в урлу /u/mc. Иначе при перефетче придётся брутфорсить на стороне клиента: ага, 10000 айдишников — отлуп, 1000 айдишников — отлуп, 500 — отлуп, 389 — норм... Запишем, что в этой станции 389.
А зачем?
[#]
Re: Дополнения к стандарту
revoltech(spnet, 4) — Andrew Lobanov
2024-10-31 09:02:02
AL> Зачем? Усложнение ради усложнения? Так IDEC не про это, а про дубовую простоту.
Это как раз и было бы про дубовую простоту парсинга. Ключ-значение. Всё однозначно.
[#]
Re: Дополнения к стандарту
revoltech(spnet, 4) — hugeping
2024-10-31 09:09:58
hugeping> Например, в данном случае, в один запрос запиханы разные лимиты слайсов для разных эх. Зачем?
Чтобы не качать лишнее.
hugeping> Видимо, предполагается что "умный" админ будет настраивать фетч таким образом под станцию, что задаст разные лимиты для эх разной наполненности? Зачем этот ужас? Придумайте, как в реальности вы будете это использовать?
В реальности — точно так же, как и твой адаптивный фетч сейчас это делает, только без необходимости предварительно мурыжить каждую эху отдельно.
hugeping> По 16 msgid забирать чистоплюство не позволяет?
Накладные расходы не позволяют. Когда станция тормозит, это особо заметно.
Сейчас у меня в stations.txt напротив каждой ноды стоит число. Если непонятно, сколько сообщений нода позволяет забрать за раз, ставлю 12, ибо это случай с tgi и его ограничением 256 символов на гет. Андрей не озвучивал ограничение spline-online, поэтому там тоже стоит 12, и делать полный перефетч — это боль с такой-то скоростью отдачи. А бывает, что надо. Например, когда я внутренний формат базы поменял, добавив поле.
hugeping> Моё мнение -- надо замораживать вариант драфта Андрея.
Я-то не против, просто предлагаю вещи, которые облегчат жизнь, пока не поздно.
[#]
Тест скорости фетча (+потеряшки)
tuple(ping,54) — hugeping
2024-10-31 09:37:10
hugeping> Можете скачать ii-go и сделать полное клонирование моей станции и написать, сколько это заняло времени.
Активного участия в дискуссиях не принимал, но решил попробовать:
$ time ./ii-tool fetch https://club.hugeping.ru
INFO: 2024/10/31 12:20:50 Start fetcher(s) for https://club.hugeping.ru
INFO: 2024/10/31 12:20:50 Get https://club.hugeping.ru/u/e/pipe.2032
INFO: 2024/10/31 12:20:50 Get https://club.hugeping.ru/u/e/std.rein
...
real 0m30,322s
user 0m9,286s
sys 0m4,117s
При фетче были ошибки на некоторые сообщения, у которых обнаружили "wrong repto format":
-
ii://z8W283Fkra8J96OrKQCC
-
ii://TKcKYfkzLXg3YU3iMQrS
-
ii://nXdcHnk0Y4UunGNNUIwi
-
ii://VJPNtsUz2RhjJUXPAqZs
-
ii://GInGJYvgNySpTJGHmk8U
-
ii://8vRmig2SXkHzCmgqFHOI
-
ii://XLMzTeZG3uvc9kJIjUpU
-
ii://2xsAUpSzT1kmFLiAP7TN
-
ii://OANneaKiLh1Ft7Gx0NEP
Как я понял: эти сообщения существуют, но сообщения, которые записаны в их repto, не существуют. Поэтому их веб-морда показать не может, а они есть. Потеряшки?
[#]
Re: Тест скорости фетча (+потеряшки)
hugeping(ping,1) — tuple
2024-10-31 09:50:52
tuple> Как я понял: эти сообщения существуют, но сообщения, которые записаны в их repto, не существуют. Поэтому их веб-морда показать не может, а они есть. Потеряшки?
Возможно, это не очень хорошо. Судя по коду, DecodBundle отбрасывает сообщение если в нём неверный repto. То-есть дело не в веб морде даже. Потом подумаю, что лучше с этим сделать. Пока так.
[#]
Re: Тест скорости фетча (+потеряшки)
hugeping(ping,1) — hugeping
2024-10-31 09:54:59
hugeping> Возможно, это не очень хорошо. Судя по коду, DecodBundle отбрасывает сообщение если в нём неверный repto. То-есть дело не в веб морде даже. Потом подумаю, что лучше с этим сделать. Пока так.
Да нет, вру. Там проверяется на корректность ID всего лишь. Странно. Проверю.
[#]
Re: Тест скорости фетча (+потеряшки)
hugeping(ping,1) — hugeping
2024-10-31 09:58:29
hugeping> Да нет, вру. Там проверяется на корректность ID всего лишь. Странно. Проверю.
У этих сообщений repto не соответствует формату. Не 20 символов. Таки сообщения я стал дропать на приёме, после того случая недавнего. Но старые сообщения остались, видимо, битые.
[#]
Re: Дополнения к стандарту
Andrew Lobanov(tavern,1) — revoltech
2024-10-31 10:43:12
AL>> Не вижу в нём смысла.
revoltech> Как клиенту понять, сколько сообщений максимум можно забрать за один запрос?
Зачем ему это понимать?
[#]
Re: Дополнения к стандарту
Andrew Lobanov(tavern,1) — revoltech
2024-10-31 10:43:17
AL>> Зачем? Усложнение ради усложнения? Так IDEC не про это, а про дубовую простоту.
revoltech> Это как раз и было бы про дубовую простоту парсинга. Ключ-значение. Всё однозначно.
Тут слайс, тут волшебное слово, тут хэш. Сиди, разбирай.
[#]
Re: Дополнения к стандарту
Andrew Lobanov(tavern,1) — hugeping
2024-10-31 10:43:24
hugeping> Я тут несколько дней сдерживаюсь. К тому же, довольно сильно приболел.
hugeping> Но сдерживаться мне всё тяжелее конечно...
hugeping> Понимаю, что меня не воспримут, всё-таки напишу.
hugeping> Подумайте, что за задачи вы решаете?
[skipped]
Подписываюсь под каждым словом.
[#]
Re: Дополнения к стандарту
Andrew Lobanov(tavern,1) — revoltech
2024-10-31 10:43:25
hugeping>> Например, в данном случае, в один запрос запиханы разные лимиты слайсов для разных эх. Зачем?
revoltech> Чтобы не качать лишнее.
Чтобы что?
hugeping>> Видимо, предполагается что "умный" админ будет настраивать фетч таким образом под станцию, что задаст разные лимиты для эх разной наполненности? Зачем этот ужас? Придумайте, как в реальности вы будете это использовать?
revoltech> В реальности — точно так же, как и твой адаптивный фетч сейчас это делает, только без необходимости предварительно мурыжить каждую эху отдельно.
Лучше мурыжить все эхи пока все слайсы не уляжутся. И этот человек говорит мне о том, чтобы не качать лишнего. Будь последователен.
hugeping>> По 16 msgid забирать чистоплюство не позволяет?
revoltech> Накладные расходы не позволяют. Когда станция тормозит, это особо заметно.
revoltech> Сейчас у меня в stations.txt напротив каждой ноды стоит число. Если непонятно, сколько сообщений нода позволяет забрать за раз, ставлю 12, ибо это случай с tgi и его ограничением 256 символов на гет. Андрей не озвучивал ограничение spline-online, поэтому там тоже стоит 12, и делать полный перефетч — это боль с такой-то скоростью отдачи. А бывает, что надо. Например, когда я внутренний формат базы поменял, добавив поле.
hugeping>> Моё мнение -- надо замораживать вариант драфта Андрея.
revoltech> Я-то не против, просто предлагаю вещи, которые облегчат жизнь, пока не поздно.
Они ни облегчат, ни усложнят жизнь. Просто придётся делать бесполезную работу.
[#]
Re: Дополнения к стандарту
revoltech(spnet, 4) — Andrew Lobanov
2024-10-31 10:53:10
AL> Зачем ему это понимать?
Да блин. Моделируем ситуацию. Клиент пришёл в сеть. Без готовой базы сообщений, без ничего. Выкачивает список эх по /list.txt. Выкачивает по /u/e/[список_эх] айдишники сообщений. Их овердофига. Дальше как ему знать, по сколько айдишников группировать для посыла одного GET /u/m, если ни станция, ни стандарт об этом ничего не говорят? Он может сгруппировать по 16 и получить ошибку на tgi, каковы дальнейшие действия?
[#]
Re: Дополнения к стандарту
Andrew Lobanov(tavern,1) — revoltech
2024-10-31 11:26:48
AL>> Зачем ему это понимать?
revoltech> Да блин. Моделируем ситуацию. Клиент пришёл в сеть. Без готовой базы сообщений, без ничего. Выкачивает список эх по /list.txt. Выкачивает по /u/e/[список_эх] айдишники сообщений. Их овердофига. Дальше как ему знать, по сколько айдишников группировать для посыла одного GET /u/m, если ни станция, ни стандарт об этом ничего не говорят? Он может сгруппировать по 16 и получить ошибку на tgi, каковы дальнейшие действия?
Пинать сисопа своего аплинка. Потому что такие короткие урлы это издевательство.
[#]
Re: Дополнения к стандарту
hugeping(ping,1) — revoltech
2024-10-31 11:34:18
AL>> Зачем ему это понимать?
revoltech> Он может сгруппировать по 16 и получить ошибку на tgi, каковы дальнейшие действия?
Варианты:
1) tgstation считать аномалией и написать админу, чтобы он сделал "стандартные 8k" как рекомендовано в RFC:
https://www.rfc-editor.org/rfc/rfc9110.html#section-4.1
It is RECOMMENDED that all senders and recipients support, at a minimum, URIs with lengths of 8000 octets in protocol elements.
2) Увидев это, задать параметр поменьше для фетча конкретно с tgi и оставить
3) Расширить станд.... ^W тьфу! :)
[#]
Re: Дополнения к стандарту
tuple(ping,54) — hugeping
2024-10-31 11:37:57
hugeping> tgstation считать аномалией
tgi же неоднократно просил считать владелец станцией экспериментов и не фетчиться с неё.
[#]
Re: Дополнения к стандарту
revoltech(spnet, 4) — Andrew Lobanov
2024-10-31 12:03:23
AL> Пинать сисопа своего аплинка. Потому что такие короткие урлы это издевательство.
Хорошо. Какие — не издевательство? Сколько айдишников скачивать по умолчанию? Где проходит граница между «слишком жирно» и «пора пинать сисопа»?
Может, в стандарте хотя бы рекомендованное число указать в таком случае? Опытным путём вот выяснилось, что апачу 389 айдишников можно скормить в /u/m на дефолтных настройках. А на spline-online сколько, например?
[#]
Re: Дополнения к стандарту
revoltech(spnet, 4) — hugeping
2024-10-31 12:06:15
hugeping> It is RECOMMENDED that all senders and recipients support, at a minimum, URIs with lengths of 8000 octets in protocol elements.
Так, может, тогда и в стандарте прописать |(8000 - 5) / 21| = 380 айдишников рекомендованным максимумом для отдачи через /u/m?
[#]
Re: Дополнения к стандарту
hugeping(ping,1) — revoltech
2024-10-31 12:25:59
hugeping>> It is RECOMMENDED that all senders and recipients support, at a minimum, URIs with lengths of 8000 octets in protocol elements.
revoltech> Так, может, тогда и в стандарте прописать |(8000 - 5) / 21| = 380 айдишников рекомендованным максимумом для отдачи через /u/m?
Всё-таки, это не аксиома. Тут мы зависим от внешнего фактора. Так что я бы написал что-то вроде:
> При составных запросах следует учесть возможные ограничения сервера на максимальную длину. Поэтому в общем случае запросы следует разбивать на части ... итд
Главная мысль в том, что фетчер всё равно должен содержать в себе логику разбивки на запросы. А размер "пачки" -- дело второе. Я бы вообще > 16 или 32 не ставил бы никогда.
[#]
Re: Дополнения к стандарту
revoltech(spnet, 4) — hugeping
2024-10-31 12:39:44
hugeping> Всё-таки, это не аксиома. Тут мы зависим от внешнего фактора.
Не аксиома, но вполне разумное значение по умолчанию. Сисопа проще пнуть на документальном уровне и пусть объясняет, почему приём 380 айдишников в /u/m для него проблема.
hugeping> Я бы вообще > 16 или 32 не ставил бы никогда.
Ну вот для случая полного перефетча это как раз издевательство, но пусть, лишь бы нода и 380 поддерживала.
[#]
Re: Дополнения к стандарту
hugeping(ping,1) — revoltech
2024-10-31 12:53:52
revoltech> Ну вот для случая полного перефетча это как раз издевательство, но пусть, лишь бы нода и 380 поддерживала.
Ну там выше tuple скинул сколько полный фетч занимает времени с моей станции. А ты видел на чём она работает? ;) И сколько там в одном запросе? Так что я по прежнему не вижу проблем. Но раз кому-то очень важно, чтобы в одном запросе шло 380 сообщений, ну пусть так. Но в стандарте я бы явно не фиксировал эти числа. Написал бы про общую проблему.
[#]
Re: Тест скорости фетча (+потеряшки)
shaos(spnet, 2) — hugeping
2024-10-31 16:34:11
Было несколько сообщение с 19-символьными msgid - я раньше писал про это.
Их можно вернуть в строй, добавив нолик в конце и поправив repto, где на них ссылаются.
[#]
Re: Дополнения к стандарту
shaos(spnet, 2) — tuple
2024-10-31 16:46:09
> tgi же неоднократно просил считать владелец станцией экспериментов и не фетчиться с неё.
Ну может кого и просил, но мы с ним в сентябре 2022 года по е-мейлу договорились взаимно фетчить idec.talks и zx.spectrum, а потом я ещё bot.habr.rss у него начал забирать.
[#]
Re: Дополнения к стандарту
shaos(spnet, 2) — revoltech
2024-10-31 16:48:10
Лучше написать не больше 380 т.к. вебсервер может такое не пережувать
И наверное надо метод POST добавить (я у себя добавлю)
[#]
Re: Дополнения к стандарту
revoltech(spnet, 4) — shaos
2024-10-31 16:52:05
shaos> Лучше написать не больше 380 т.к. вебсервер может такое не пережувать
Ну я о том же, можно сказать, что 380 — максимум, который нужно поддерживать, а дальше уже на усмотрение владельца сервера.
shaos> И наверное надо метод POST добавить (я у себя добавлю)
Только за, но здесь почему-то нашлись принципиальные противники этой идеи.
[#]
Re: Дополнения к стандарту
shaos(spnet, 2) — shaos
2024-10-31 17:03:50
Рекомендовать 32 т.к. оно вообще не через http-сервер может идти, а через самописный (кстати bottle.py какое ограничение имеет?)
[#]
Re: Дополнения к стандарту
revoltech(spnet, 4) — shaos
2024-10-31 17:05:42
shaos> Рекомендовать 32 т.к. оно вообще не через http-сервер может идти, а через самописный (кстати bottle.py какое ограничение имеет?)
Да у самописных вообще ограничений нет обычно.
[#]
Re: Дополнения к стандарту
Andrew Lobanov(tavern,1) — revoltech
2024-10-31 18:36:32
AL>> Пинать сисопа своего аплинка. Потому что такие короткие урлы это издевательство.
revoltech> Хорошо. Какие — не издевательство? Сколько айдишников скачивать по умолчанию? Где проходит граница между «слишком жирно» и «пора пинать сисопа»?
10+ лет качаем по 40. Полёт нормальный. Зачем выдумывать себе трудности? Чтобы героически их преодолевать?
revoltech> Может, в стандарте хотя бы рекомендованное число указать в таком случае? Опытным путём вот выяснилось, что апачу 389 айдишников можно скормить в /u/m на дефолтных настройках. А на spline-online сколько, например?
Настройки веб-сервера выходят за рамки стандарта.
[#]
Re: Дополнения к стандарту
Andrew Lobanov(tavern,1) — revoltech
2024-10-31 18:36:33
hugeping>> It is RECOMMENDED that all senders and recipients support, at a minimum, URIs with lengths of 8000 octets in protocol elements.
revoltech> Так, может, тогда и в стандарте прописать |(8000 - 5) / 21| = 380 айдишников рекомендованным максимумом для отдачи через /u/m?
Это уже прописано в стандарте. Только почему это должно быть прописано в стандарте IDEC?
[#]
Re: Дополнения к стандарту
Andrew Lobanov(tavern,1) — revoltech
2024-10-31 18:36:33
hugeping>> Всё-таки, это не аксиома. Тут мы зависим от внешнего фактора.
revoltech> Не аксиома, но вполне разумное значение по умолчанию. Сисопа проще пнуть на документальном уровне и пусть объясняет, почему приём 380 айдишников в /u/m для него проблема.
Хорошо. Я укажу в стандарте 40. Все, кто качает больше или предоставляют меньше, не соблюдают стандарт.
[#]
Re: Дополнения к стандарту
Andrew Lobanov(tavern,1) — revoltech
2024-10-31 18:38:25
shaos>> И наверное надо метод POST добавить (я у себя добавлю)
revoltech> Только за, но здесь почему-то нашлись принципиальные противники этой идеи.
Эта идея решает примерно - проблем. Так зачем?
Могу добавить, оставив упоминание про потолок в 40 айдишников на запрос.
[#]
Re: Дополнения к стандарту
ahamai(blackcat, 2) — revoltech
2024-10-31 18:26:11
Большие запросы вообще не нужны. Во-первых, они не нужны в принципе, я вообще не вижу разницы между запросами по 10 и по 40 сообщений, я и так и так легко выкачиваю всю сеть. Во-вторых, это ставит колом однопоточные серверы. Я бы запросы более 40 мессаг за раз расценивал бы как XAB.
[#]
Re: Дополнения к стандарту
ahamai(blackcat, 2) — hugeping
2024-10-31 18:59:20
> Например, в данном случае, в один запрос запиханы разные лимиты слайсов для разных эх. Зачем?
Так это была изначальная идея - для экономии трафика. я всегда думал, что оно именно так и сделано, там 100 rss сообщений за час их и забрали, там 1 за неделю. а так это какая-то полумера, ни туда ни сюда.
> Потом, Рома трясёт своим ?sf=hash - как замену слайсов.
Приехали. Я не использую ?sf. Я не собираюсь использовать ?sf. Оно создано ровно для одного случая, работы в условиях медленного интернета. Для чего, как заявлялось, и делался idec. И, в отличие от idec, он делает ровно то, что от него просят, даёт одним запросом ровно то, что нужно, минимальный объём сообщений.
> На самом деле этот sf=hash при своей красоте, всё-таки, хуже слайсов. Во первых, даже с хешем надо делать запрос внахлёст с запасом (не забываем про то, что порядок сообщений на ноде может не совпадать с нашим)
Не надо так делать. В 99% случаев запрос вернёт ровно то, что от него хотят. В остальных случаях, скорее всего, поможет только полный фетч.
> и нам все равно придётся самим на своей станции находить n сообщение от конца в эхе и брать затем его хеш чтобы сформировать запрос. Те же слайсы, вид сбоку.
Только все эхи опрашиваются одним запросом, и с нужным количеством сообщений.
> Ну и во-вторых, sf решает одну конкретную задачу, а слайсы - универсальны. Слайсы делают возможным адаптивный фетч и онлайн просмотр.
То, что называется слайсы, у меня называется lim. Сделано одной строчкой кода. Совместимо вообще со всем, не ломает /u/e/, и даже клиенты, которые понятия не имеют о lim, могут им пользоваться.
Адаптивный фетчинг это оверинжиниринг, программирование ради программирования, он вообще не даёт гарантий, в станциях где нет формальных эх а сортировка идёт по timestamp, могут быть вкинуты старые сообщения и такой фетчинг их не увидит. В нормальных условиях я вообще не вижу проблем гонять полные эхи, ибо только они дают полную гарантию. Для экономии трафка можно использовать ?h, его использование в гейтовании с shaos сократило дневной трафик с 12 мб до 2.
> В общем, попытки решить какие-то несуществующие проблемы и навязать какие-то свои оценки. Чего я боялся, то и происходит. Лебедь рак и щука.
Проблема была в проектировании. Некорректном дизайне. В сломе того, что просто работало и было простым, как три копейки, ради решения несуществующих проблем и каких-то непонятных смен стандарта, которые ничего не дают, кроме экономии трафика, которой тоже нет, потому что у тебя либо постоянные новые запросы, новые коннекции, новые строчки в логе сервера и так далее, да там tcp фреймы больше сожрут чем трафика сэкономится :)
Забавно, я посмотрел архив старых эх - я постоянно из протокола что-то выкидывал, пока не остались /e /m /u/e /u/m, и всё это не достигло предельной простоты. А щас только что-то добавляют. Да сколько угодно. Но не надо лезть в /u/e. Это база из баз, фейлбек из фейлбеков, он должен быть простым, примитивным, кодиться за три строчки кода на любом языке и быть единой везде. Расширяйте как хотите, но расширяйте отдельные методы, без x/feaures и прочего фиг пойми зачем, может нода работать по новому - запрашиваем, не может - фэлбэчимся на старое. Или это можно прописать в конфиге, например как здесь:
****
ii.about.2014
1396407760
51t
lenina,1
51t
Re: есть идея вообще всё нафиг переделать
ладно, эксперименты - потом. в принципе, я тут подумал, можно всё решить в рамках существующей реалзиации
1. сделать рядом с /z/ ещё одну (а не 8, как планировалось) реализацию, /u/ - без zlib и для обычного base64. /u/ должны будут поддерживать все серверы и все клиенты, всегда. /z/ - пока будет вотчина python, а там посмотрим.
2. так и сделать - вместо хттп://51t.ru/ писать хттп://51t.ru/z/. или хттп://51t.ru/u/. или даже хттп://мойсайт.ру/ii.php?q=/u/, по нему и определять, если на /z/ заканчивается - значит схема python, если на /u/ - значит плоская схема. для получения - всегда останутся /m/ и /e/
3. пока будет опциональным. пусть внедряется. :)
****
А стандарт обмена между станциями это стандарт обмена между станциями, пусть хоть на берёзовых бруньках обмениваются, это договорённости сисопов. Большие инконсистентные эхи - это проблема, которая была решена изначально, но потом заменена на другое решение, для которой и потребовались слайсы, чем больше изменений, тем больше новых сущностей. Это всё - плохой дизайн.