# Re: Дополнения к стандарту
hugeping (ping,1) → revoltech – 12:53:52 2024-10-31
revoltech> Ну вот для случая полного перефетча это как раз издевательство, но пусть, лишь бы нода и 380 поддерживала.
Ну там выше tuple скинул сколько полный фетч занимает времени с моей станции. А ты видел на чём она работает? ;) И сколько там в одном запросе? Так что я по прежнему не вижу проблем. Но раз кому-то очень важно, чтобы в одном запросе шло 380 сообщений, ну пусть так. Но в стандарте я бы явно не фиксировал эти числа. Написал бы про общую проблему.
hugeping (ping,1) → revoltech – 12:53:52 2024-10-31
revoltech> Ну вот для случая полного перефетча это как раз издевательство, но пусть, лишь бы нода и 380 поддерживала.
Ну там выше tuple скинул сколько полный фетч занимает времени с моей станции. А ты видел на чём она работает? ;) И сколько там в одном запросе? Так что я по прежнему не вижу проблем. Но раз кому-то очень важно, чтобы в одном запросе шло 380 сообщений, ну пусть так. Но в стандарте я бы явно не фиксировал эти числа. Написал бы про общую проблему.
# Re: Дополнения к стандарту
revoltech (spnet, 4) → hugeping – 12:39:44 2024-10-31
hugeping> Всё-таки, это не аксиома. Тут мы зависим от внешнего фактора.
Не аксиома, но вполне разумное значение по умолчанию. Сисопа проще пнуть на документальном уровне и пусть объясняет, почему приём 380 айдишников в /u/m для него проблема.
hugeping> Я бы вообще > 16 или 32 не ставил бы никогда.
Ну вот для случая полного перефетча это как раз издевательство, но пусть, лишь бы нода и 380 поддерживала.
revoltech (spnet, 4) → hugeping – 12:39:44 2024-10-31
hugeping> Всё-таки, это не аксиома. Тут мы зависим от внешнего фактора.
Не аксиома, но вполне разумное значение по умолчанию. Сисопа проще пнуть на документальном уровне и пусть объясняет, почему приём 380 айдишников в /u/m для него проблема.
hugeping> Я бы вообще > 16 или 32 не ставил бы никогда.
Ну вот для случая полного перефетча это как раз издевательство, но пусть, лишь бы нода и 380 поддерживала.
# Re: Дополнения к стандарту
hugeping (ping,1) → revoltech – 12:25:59 2024-10-31
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 не ставил бы никогда.
hugeping (ping,1) → revoltech – 12:25:59 2024-10-31
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 – 12:06:15 2024-10-31
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?
revoltech (spnet, 4) → hugeping – 12:06:15 2024-10-31
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: Дополнения к стандарту
revoltech (spnet, 4) → Andrew Lobanov – 12:03:23 2024-10-31
AL> Пинать сисопа своего аплинка. Потому что такие короткие урлы это издевательство.
Хорошо. Какие — не издевательство? Сколько айдишников скачивать по умолчанию? Где проходит граница между «слишком жирно» и «пора пинать сисопа»?
Может, в стандарте хотя бы рекомендованное число указать в таком случае? Опытным путём вот выяснилось, что апачу 389 айдишников можно скормить в /u/m на дефолтных настройках. А на spline-online сколько, например?
revoltech (spnet, 4) → Andrew Lobanov – 12:03:23 2024-10-31
AL> Пинать сисопа своего аплинка. Потому что такие короткие урлы это издевательство.
Хорошо. Какие — не издевательство? Сколько айдишников скачивать по умолчанию? Где проходит граница между «слишком жирно» и «пора пинать сисопа»?
Может, в стандарте хотя бы рекомендованное число указать в таком случае? Опытным путём вот выяснилось, что апачу 389 айдишников можно скормить в /u/m на дефолтных настройках. А на spline-online сколько, например?
# Re: Дополнения к стандарту
tuple (ping,54) → hugeping – 11:37:57 2024-10-31
hugeping> tgstation считать аномалией
tgi же неоднократно просил считать владелец станцией экспериментов и не фетчиться с неё.
tuple (ping,54) → hugeping – 11:37:57 2024-10-31
hugeping> tgstation считать аномалией
tgi же неоднократно просил считать владелец станцией экспериментов и не фетчиться с неё.
# Re: Дополнения к стандарту
hugeping (ping,1) → revoltech – 11:34:18 2024-10-31
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 тьфу! :)
hugeping (ping,1) → revoltech – 11:34:18 2024-10-31
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: Дополнения к стандарту
Andrew Lobanov (tavern,1) → revoltech – 11:26:48 2024-10-31
AL>> Зачем ему это понимать?
revoltech> Да блин. Моделируем ситуацию. Клиент пришёл в сеть. Без готовой базы сообщений, без ничего. Выкачивает список эх по /list.txt. Выкачивает по /u/e/[список_эх] айдишники сообщений. Их овердофига. Дальше как ему знать, по сколько айдишников группировать для посыла одного GET /u/m, если ни станция, ни стандарт об этом ничего не говорят? Он может сгруппировать по 16 и получить ошибку на tgi, каковы дальнейшие действия?
Пинать сисопа своего аплинка. Потому что такие короткие урлы это издевательство.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → revoltech – 11:26:48 2024-10-31
AL>> Зачем ему это понимать?
revoltech> Да блин. Моделируем ситуацию. Клиент пришёл в сеть. Без готовой базы сообщений, без ничего. Выкачивает список эх по /list.txt. Выкачивает по /u/e/[список_эх] айдишники сообщений. Их овердофига. Дальше как ему знать, по сколько айдишников группировать для посыла одного GET /u/m, если ни станция, ни стандарт об этом ничего не говорят? Он может сгруппировать по 16 и получить ошибку на tgi, каковы дальнейшие действия?
Пинать сисопа своего аплинка. Потому что такие короткие урлы это издевательство.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: Дополнения к стандарту
revoltech (spnet, 4) → Andrew Lobanov – 10:53:10 2024-10-31
AL> Зачем ему это понимать?
Да блин. Моделируем ситуацию. Клиент пришёл в сеть. Без готовой базы сообщений, без ничего. Выкачивает список эх по /list.txt. Выкачивает по /u/e/[список_эх] айдишники сообщений. Их овердофига. Дальше как ему знать, по сколько айдишников группировать для посыла одного GET /u/m, если ни станция, ни стандарт об этом ничего не говорят? Он может сгруппировать по 16 и получить ошибку на tgi, каковы дальнейшие действия?
revoltech (spnet, 4) → Andrew Lobanov – 10:53:10 2024-10-31
AL> Зачем ему это понимать?
Да блин. Моделируем ситуацию. Клиент пришёл в сеть. Без готовой базы сообщений, без ничего. Выкачивает список эх по /list.txt. Выкачивает по /u/e/[список_эх] айдишники сообщений. Их овердофига. Дальше как ему знать, по сколько айдишников группировать для посыла одного GET /u/m, если ни станция, ни стандарт об этом ничего не говорят? Он может сгруппировать по 16 и получить ошибку на tgi, каковы дальнейшие действия?
# Re: Дополнения к стандарту
Andrew Lobanov (tavern,1) → revoltech – 10:43:25 2024-10-31
hugeping>> Например, в данном случае, в один запрос запиханы разные лимиты слайсов для разных эх. Зачем?
revoltech> Чтобы не качать лишнее.
Чтобы что?
hugeping>> Видимо, предполагается что "умный" админ будет настраивать фетч таким образом под станцию, что задаст разные лимиты для эх разной наполненности? Зачем этот ужас? Придумайте, как в реальности вы будете это использовать?
revoltech> В реальности — точно так же, как и твой адаптивный фетч сейчас это делает, только без необходимости предварительно мурыжить каждую эху отдельно.
Лучше мурыжить все эхи пока все слайсы не уляжутся. И этот человек говорит мне о том, чтобы не качать лишнего. Будь последователен.
hugeping>> По 16 msgid забирать чистоплюство не позволяет?
revoltech> Накладные расходы не позволяют. Когда станция тормозит, это особо заметно.
revoltech> Сейчас у меня в stations.txt напротив каждой ноды стоит число. Если непонятно, сколько сообщений нода позволяет забрать за раз, ставлю 12, ибо это случай с tgi и его ограничением 256 символов на гет. Андрей не озвучивал ограничение spline-online, поэтому там тоже стоит 12, и делать полный перефетч — это боль с такой-то скоростью отдачи. А бывает, что надо. Например, когда я внутренний формат базы поменял, добавив поле.
hugeping>> Моё мнение -- надо замораживать вариант драфта Андрея.
revoltech> Я-то не против, просто предлагаю вещи, которые облегчат жизнь, пока не поздно.
>> Читать далее
Andrew Lobanov (tavern,1) → revoltech – 10:43:25 2024-10-31
hugeping>> Например, в данном случае, в один запрос запиханы разные лимиты слайсов для разных эх. Зачем?
revoltech> Чтобы не качать лишнее.
Чтобы что?
hugeping>> Видимо, предполагается что "умный" админ будет настраивать фетч таким образом под станцию, что задаст разные лимиты для эх разной наполненности? Зачем этот ужас? Придумайте, как в реальности вы будете это использовать?
revoltech> В реальности — точно так же, как и твой адаптивный фетч сейчас это делает, только без необходимости предварительно мурыжить каждую эху отдельно.
Лучше мурыжить все эхи пока все слайсы не уляжутся. И этот человек говорит мне о том, чтобы не качать лишнего. Будь последователен.
hugeping>> По 16 msgid забирать чистоплюство не позволяет?
revoltech> Накладные расходы не позволяют. Когда станция тормозит, это особо заметно.
revoltech> Сейчас у меня в stations.txt напротив каждой ноды стоит число. Если непонятно, сколько сообщений нода позволяет забрать за раз, ставлю 12, ибо это случай с tgi и его ограничением 256 символов на гет. Андрей не озвучивал ограничение spline-online, поэтому там тоже стоит 12, и делать полный перефетч — это боль с такой-то скоростью отдачи. А бывает, что надо. Например, когда я внутренний формат базы поменял, добавив поле.
hugeping>> Моё мнение -- надо замораживать вариант драфта Андрея.
revoltech> Я-то не против, просто предлагаю вещи, которые облегчат жизнь, пока не поздно.
>> Читать далее
# Re: Разбор idec
Andrew Lobanov (tavern,1) → hugeping – 10:43:25 2024-10-31
shaos>> Неа - опять не сработало…
hugeping> Возможно, потому что в сообщении нет последнего перевода строки ( см: http://shaos.net:8085/ii-point.php?q=/m/DpizUAp7CfgxVznSUul4 )
По идее, это без разницы. $ -- это в любом случае конец строки.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → hugeping – 10:43:25 2024-10-31
shaos>> Неа - опять не сработало…
hugeping> Возможно, потому что в сообщении нет последнего перевода строки ( см: http://shaos.net:8085/ii-point.php?q=/m/DpizUAp7CfgxVznSUul4 )
По идее, это без разницы. $ -- это в любом случае конец строки.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: Разбор idec
Andrew Lobanov (tavern,1) → shaos – 10:43:24 2024-10-31
shaos> Вот почему в предыдущем сообщении оно только на последний ==== среагировало? Пустую строку надо до?
Вангую, что это потому, что не было пустой строки в конце сообщения. Попробуй добавить и оно сломается совсем :)
shaos> ====
shaos> again?
shaos> ====
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → shaos – 10:43:24 2024-10-31
shaos> Вот почему в предыдущем сообщении оно только на последний ==== среагировало? Пустую строку надо до?
Вангую, что это потому, что не было пустой строки в конце сообщения. Попробуй добавить и оно сломается совсем :)
shaos> ====
shaos> again?
shaos> ====
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: Разбор idec
Andrew Lobanov (tavern,1) → shaos – 10:43:24 2024-10-31
shaos> Нету пробелов после ====
shaos> Он просто иногда работает, но чаще не работает
shaos> ====
shaos> here?
shaos> ====
А может, это от тех деятелей, которые \n\r шлют вместо \n? Попробуй поэкспериментировать с этим.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → shaos – 10:43:24 2024-10-31
shaos> Нету пробелов после ====
shaos> Он просто иногда работает, но чаще не работает
shaos> ====
shaos> here?
shaos> ====
А может, это от тех деятелей, которые \n\r шлют вместо \n? Попробуй поэкспериментировать с этим.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: Разбор idec
Andrew Lobanov (tavern,1) → shaos – 10:43:24 2024-10-31
shaos> Ну проблему нелогичности решает, на которую некоторые указывают :)
Нелогичность пока недоказана :)
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → shaos – 10:43:24 2024-10-31
shaos> Ну проблему нелогичности решает, на которую некоторые указывают :)
Нелогичность пока недоказана :)
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: Дополнения к стандарту
Andrew Lobanov (tavern,1) → hugeping – 10:43:24 2024-10-31
hugeping> Я тут несколько дней сдерживаюсь. К тому же, довольно сильно приболел.
hugeping> Но сдерживаться мне всё тяжелее конечно...
hugeping> Понимаю, что меня не воспримут, всё-таки напишу.
hugeping> Подумайте, что за задачи вы решаете?
[skipped]
Подписываюсь под каждым словом.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → hugeping – 10:43:24 2024-10-31
hugeping> Я тут несколько дней сдерживаюсь. К тому же, довольно сильно приболел.
hugeping> Но сдерживаться мне всё тяжелее конечно...
hugeping> Понимаю, что меня не воспримут, всё-таки напишу.
hugeping> Подумайте, что за задачи вы решаете?
[skipped]
Подписываюсь под каждым словом.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: Дополнения к стандарту
Andrew Lobanov (tavern,1) → revoltech – 10:43:17 2024-10-31
AL>> Зачем? Усложнение ради усложнения? Так IDEC не про это, а про дубовую простоту.
revoltech> Это как раз и было бы про дубовую простоту парсинга. Ключ-значение. Всё однозначно.
Тут слайс, тут волшебное слово, тут хэш. Сиди, разбирай.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → revoltech – 10:43:17 2024-10-31
AL>> Зачем? Усложнение ради усложнения? Так IDEC не про это, а про дубовую простоту.
revoltech> Это как раз и было бы про дубовую простоту парсинга. Ключ-значение. Всё однозначно.
Тут слайс, тут волшебное слово, тут хэш. Сиди, разбирай.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: Дополнения к стандарту
Andrew Lobanov (tavern,1) → revoltech – 10:43:12 2024-10-31
AL>> Не вижу в нём смысла.
revoltech> Как клиенту понять, сколько сообщений максимум можно забрать за один запрос?
Зачем ему это понимать?
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → revoltech – 10:43:12 2024-10-31
AL>> Не вижу в нём смысла.
revoltech> Как клиенту понять, сколько сообщений максимум можно забрать за один запрос?
Зачем ему это понимать?
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: Разбор idec
Andrew Lobanov (tavern,1) → ahamai – 10:43:05 2024-10-31
>> ahamai просто не помнит свой же стандарт. Надеюсь, у него всё хорошо.
ahamai> В бандле только эхи и msgid.
Ещё пустая строка.
ahamai> Эхи с точками, всё осталное msgid. Если там что то ещё, падай а не игнорируй
Откуда оно там возьмётся?
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → ahamai – 10:43:05 2024-10-31
>> ahamai просто не помнит свой же стандарт. Надеюсь, у него всё хорошо.
ahamai> В бандле только эхи и msgid.
Ещё пустая строка.
ahamai> Эхи с точками, всё осталное msgid. Если там что то ещё, падай а не игнорируй
Откуда оно там возьмётся?
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: Тест скорости фетча (+потеряшки)
hugeping (ping,1) → hugeping – 09:58:29 2024-10-31
hugeping> Да нет, вру. Там проверяется на корректность ID всего лишь. Странно. Проверю.
У этих сообщений repto не соответствует формату. Не 20 символов. Таки сообщения я стал дропать на приёме, после того случая недавнего. Но старые сообщения остались, видимо, битые.
hugeping (ping,1) → hugeping – 09:58:29 2024-10-31
hugeping> Да нет, вру. Там проверяется на корректность ID всего лишь. Странно. Проверю.
У этих сообщений repto не соответствует формату. Не 20 символов. Таки сообщения я стал дропать на приёме, после того случая недавнего. Но старые сообщения остались, видимо, битые.
# Re: Тест скорости фетча (+потеряшки)
hugeping (ping,1) → hugeping – 09:54:59 2024-10-31
hugeping> Возможно, это не очень хорошо. Судя по коду, DecodBundle отбрасывает сообщение если в нём неверный repto. То-есть дело не в веб морде даже. Потом подумаю, что лучше с этим сделать. Пока так.
Да нет, вру. Там проверяется на корректность ID всего лишь. Странно. Проверю.
hugeping (ping,1) → hugeping – 09:54:59 2024-10-31
hugeping> Возможно, это не очень хорошо. Судя по коду, DecodBundle отбрасывает сообщение если в нём неверный repto. То-есть дело не в веб морде даже. Потом подумаю, что лучше с этим сделать. Пока так.
Да нет, вру. Там проверяется на корректность ID всего лишь. Странно. Проверю.
# Re: Тест скорости фетча (+потеряшки)
hugeping (ping,1) → tuple – 09:50:52 2024-10-31
tuple> Как я понял: эти сообщения существуют, но сообщения, которые записаны в их repto, не существуют. Поэтому их веб-морда показать не может, а они есть. Потеряшки?
Возможно, это не очень хорошо. Судя по коду, DecodBundle отбрасывает сообщение если в нём неверный repto. То-есть дело не в веб морде даже. Потом подумаю, что лучше с этим сделать. Пока так.
hugeping (ping,1) → tuple – 09:50:52 2024-10-31
tuple> Как я понял: эти сообщения существуют, но сообщения, которые записаны в их repto, не существуют. Поэтому их веб-морда показать не может, а они есть. Потеряшки?
Возможно, это не очень хорошо. Судя по коду, DecodBundle отбрасывает сообщение если в нём неверный repto. То-есть дело не в веб морде даже. Потом подумаю, что лучше с этим сделать. Пока так.
# Тест скорости фетча (+потеряшки)
tuple (ping,54) → hugeping – 09:37:10 2024-10-31
hugeping> Можете скачать ii-go и сделать полное клонирование моей станции и написать, сколько это заняло времени.
Активного участия в дискуссиях не принимал, но решил попробовать:
>> Читать далее
tuple (ping,54) → hugeping – 09:37:10 2024-10-31
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
>> Читать далее
# Re: Дополнения к стандарту
revoltech (spnet, 4) → hugeping – 09:09:58 2024-10-31
hugeping> Например, в данном случае, в один запрос запиханы разные лимиты слайсов для разных эх. Зачем?
Чтобы не качать лишнее.
hugeping> Видимо, предполагается что "умный" админ будет настраивать фетч таким образом под станцию, что задаст разные лимиты для эх разной наполненности? Зачем этот ужас? Придумайте, как в реальности вы будете это использовать?
В реальности — точно так же, как и твой адаптивный фетч сейчас это делает, только без необходимости предварительно мурыжить каждую эху отдельно.
hugeping> По 16 msgid забирать чистоплюство не позволяет?
Накладные расходы не позволяют. Когда станция тормозит, это особо заметно.
Сейчас у меня в stations.txt напротив каждой ноды стоит число. Если непонятно, сколько сообщений нода позволяет забрать за раз, ставлю 12, ибо это случай с tgi и его ограничением 256 символов на гет. Андрей не озвучивал ограничение spline-online, поэтому там тоже стоит 12, и делать полный перефетч — это боль с такой-то скоростью отдачи. А бывает, что надо. Например, когда я внутренний формат базы поменял, добавив поле.
hugeping> Моё мнение -- надо замораживать вариант драфта Андрея.
>> Читать далее
revoltech (spnet, 4) → hugeping – 09:09:58 2024-10-31
hugeping> Например, в данном случае, в один запрос запиханы разные лимиты слайсов для разных эх. Зачем?
Чтобы не качать лишнее.
hugeping> Видимо, предполагается что "умный" админ будет настраивать фетч таким образом под станцию, что задаст разные лимиты для эх разной наполненности? Зачем этот ужас? Придумайте, как в реальности вы будете это использовать?
В реальности — точно так же, как и твой адаптивный фетч сейчас это делает, только без необходимости предварительно мурыжить каждую эху отдельно.
hugeping> По 16 msgid забирать чистоплюство не позволяет?
Накладные расходы не позволяют. Когда станция тормозит, это особо заметно.
Сейчас у меня в stations.txt напротив каждой ноды стоит число. Если непонятно, сколько сообщений нода позволяет забрать за раз, ставлю 12, ибо это случай с tgi и его ограничением 256 символов на гет. Андрей не озвучивал ограничение spline-online, поэтому там тоже стоит 12, и делать полный перефетч — это боль с такой-то скоростью отдачи. А бывает, что надо. Например, когда я внутренний формат базы поменял, добавив поле.
hugeping> Моё мнение -- надо замораживать вариант драфта Андрея.
>> Читать далее
# Re: Разбор idec
hugeping (ping,1) → shaos – 08:53:04 2024-10-31
shaos> Неа - опять не сработало…
Возможно, потому что в сообщении нет последнего перевода строки ( см: http://shaos.net:8085/ii-point.php?q=/m/DpizUAp7CfgxVznSUul4 )
Только можно тестировать это в другой теме, пожалуйста? :)
P.S. Edited: 2024-10-31 08:53:11
hugeping (ping,1) → shaos – 08:53:04 2024-10-31
shaos> Неа - опять не сработало…
Возможно, потому что в сообщении нет последнего перевода строки ( см: http://shaos.net:8085/ii-point.php?q=/m/DpizUAp7CfgxVznSUul4 )
Только можно тестировать это в другой теме, пожалуйста? :)
P.S. Edited: 2024-10-31 08:53:11
# Re: Дополнения к стандарту
revoltech (spnet, 4) → Andrew Lobanov – 09:02:02 2024-10-31
AL> Зачем? Усложнение ради усложнения? Так IDEC не про это, а про дубовую простоту.
Это как раз и было бы про дубовую простоту парсинга. Ключ-значение. Всё однозначно.
revoltech (spnet, 4) → Andrew Lobanov – 09:02:02 2024-10-31
AL> Зачем? Усложнение ради усложнения? Так IDEC не про это, а про дубовую простоту.
Это как раз и было бы про дубовую простоту парсинга. Ключ-значение. Всё однозначно.