# Re: Разбор idec №2
shaos (spnet, 2) → ahamai – 20:21:12 2024-10-31
> Во-первых, изначально у меня была ошибка, ?sf не прозрачна, её нельзя добавить вообще везде. Потому что есть php-ноды, и там должно быть &.
Ну я ведь у себя поддержал list.txt?h=1 :)
Просто парсить надо будет вручную
shaos (spnet, 2) → ahamai – 20:21:12 2024-10-31
> Во-первых, изначально у меня была ошибка, ?sf не прозрачна, её нельзя добавить вообще везде. Потому что есть php-ноды, и там должно быть &.
Ну я ведь у себя поддержал list.txt?h=1 :)
Просто парсить надо будет вручную
# Re: Разбор idec №2
revoltech (spnet, 4) → ahamai – 20:11:59 2024-10-31
ahamai> это полностью ломает единость формата. /u/e должна быть везде, и должна реализовываться в 3 строках.
Так она и реализуется в 3-5 строках, если нормальные ЯП юзать. И поведение от запроса со слайсом на ноду, которая слайсы не реализует, меняться не будет: этот последний компонент просто не является валидным именем эхи. Нода, которая не умеет слайсить, должна его просто отбросить. Если она так не делает, чини реализацию.
revoltech (spnet, 4) → ahamai – 20:11:59 2024-10-31
ahamai> это полностью ломает единость формата. /u/e должна быть везде, и должна реализовываться в 3 строках.
Так она и реализуется в 3-5 строках, если нормальные ЯП юзать. И поведение от запроса со слайсом на ноду, которая слайсы не реализует, меняться не будет: этот последний компонент просто не является валидным именем эхи. Нода, которая не умеет слайсить, должна его просто отбросить. Если она так не делает, чини реализацию.
# Re: Разбор idec №2
ahamai (blackcat, 2) → revoltech – 20:01:31 2024-10-31
> А здесь не согласен. Здесь прав товарищ AL, который говорит, что поведение остаётся прежним, нужно только подкорректировать логику парсера. Ну, типа, старые /u/e никуда не деваются, нужно только посмотреть, есть ли двоеточие в последнем элементе и привет.
это полностью ломает единость формата. /u/e должна быть везде, и должна реализовываться в 3 строках. у неё не должно быть расхождений, не надо в /u/e добавлять парсеры, /u/e должна быть единой и быть везде. все остальные расширения - отдельно.
ahamai (blackcat, 2) → revoltech – 20:01:31 2024-10-31
> А здесь не согласен. Здесь прав товарищ AL, который говорит, что поведение остаётся прежним, нужно только подкорректировать логику парсера. Ну, типа, старые /u/e никуда не деваются, нужно только посмотреть, есть ли двоеточие в последнем элементе и привет.
это полностью ломает единость формата. /u/e должна быть везде, и должна реализовываться в 3 строках. у неё не должно быть расхождений, не надо в /u/e добавлять парсеры, /u/e должна быть единой и быть везде. все остальные расширения - отдельно.
# Re: Дополнения к стандарту
revoltech (spnet, 4) → ahamai – 19:45:25 2024-10-31
ahamai> если ты предоставишь бенчмарки, что выгрузка всех сообщений единым блоком хотя бы в 2 раза быстрее, чем чанками по 20 сообщений, тогда это будет интересно. тогда мож и /get вернётся.
Это зависит от местоположения клиента и ноды. В стерильных тестовых условиях, может, и не вдвое быстрее будет. А вот в реальных время установки TCP/TLS-соединения тоже существенно добавляет к общей картине. Могу на днях замерять перефетч с shaos-а после уменьшения чанка с 389 сообщений до 40. Или с ping после уменьшения с 10000 до 40... Если интересно.
revoltech (spnet, 4) → ahamai – 19:45:25 2024-10-31
ahamai> если ты предоставишь бенчмарки, что выгрузка всех сообщений единым блоком хотя бы в 2 раза быстрее, чем чанками по 20 сообщений, тогда это будет интересно. тогда мож и /get вернётся.
Это зависит от местоположения клиента и ноды. В стерильных тестовых условиях, может, и не вдвое быстрее будет. А вот в реальных время установки TCP/TLS-соединения тоже существенно добавляет к общей картине. Могу на днях замерять перефетч с shaos-а после уменьшения чанка с 389 сообщений до 40. Или с ping после уменьшения с 10000 до 40... Если интересно.
# Re: Разбор idec №2
revoltech (spnet, 4) → ahamai – 19:39:32 2024-10-31
Уважаемый, я вот вроде тебя и понимаю, и не понимаю одновременно. Например, я пришёл сюда совсем недавно. Старую ii-документацию в этих ваших интернетах уже не сыскать, все старые сайты протухли. Откуда мне было знать про «эмпирическим путём найденный» лимит в 40 мессаг, про /z/get и прочие босфоры?
ahamai> И уж если планируются расширения, совершенно точно не надо вешать какие-то костыли, чтобы вопрос "а как задать срез для каждой эхи" не имел ответа.
Здесь согласен.
ahamai> Про key/value. У босфора был такой интерфейс, /bb/key1/value1/key2/value2. Это было удобно сначала парсить в словарик, а потом с этим словариком работать, минимумом кода достигались красивые вещи, можно было делать разные запросы. Если что-то расширяешь, нужно сразу делать формат, который можно расширять, но который при этом фалбакается, если расширение не поддерживается. Зачем нагромождение ненужных сущностей, которые потом надо ещё прописывать? Когда можно сделать единый урл, единый словарик, а любой фильтр прописывать ровно одной строкой кода, и те системы, которые его не поддерживают, просто не будут по этому критерию фильтровать.
И здесь согласен.
ahamai> и что самое ужасное, при этом изменяя поведение базовых.
А здесь не согласен. Здесь прав товарищ AL, который говорит, что поведение остаётся прежним, нужно только подкорректировать логику парсера. Ну, типа, старые /u/e никуда не деваются, нужно только посмотреть, есть ли двоеточие в последнем элементе и привет.
Другое дело, что логику парсера можно было бы упростить в разы, приняв концепцию железобетонной структуры key/value/key/value/..., но уже имеем то, что имеем.
revoltech (spnet, 4) → ahamai – 19:39:32 2024-10-31
Уважаемый, я вот вроде тебя и понимаю, и не понимаю одновременно. Например, я пришёл сюда совсем недавно. Старую ii-документацию в этих ваших интернетах уже не сыскать, все старые сайты протухли. Откуда мне было знать про «эмпирическим путём найденный» лимит в 40 мессаг, про /z/get и прочие босфоры?
ahamai> И уж если планируются расширения, совершенно точно не надо вешать какие-то костыли, чтобы вопрос "а как задать срез для каждой эхи" не имел ответа.
Здесь согласен.
ahamai> Про key/value. У босфора был такой интерфейс, /bb/key1/value1/key2/value2. Это было удобно сначала парсить в словарик, а потом с этим словариком работать, минимумом кода достигались красивые вещи, можно было делать разные запросы. Если что-то расширяешь, нужно сразу делать формат, который можно расширять, но который при этом фалбакается, если расширение не поддерживается. Зачем нагромождение ненужных сущностей, которые потом надо ещё прописывать? Когда можно сделать единый урл, единый словарик, а любой фильтр прописывать ровно одной строкой кода, и те системы, которые его не поддерживают, просто не будут по этому критерию фильтровать.
И здесь согласен.
ahamai> и что самое ужасное, при этом изменяя поведение базовых.
А здесь не согласен. Здесь прав товарищ AL, который говорит, что поведение остаётся прежним, нужно только подкорректировать логику парсера. Ну, типа, старые /u/e никуда не деваются, нужно только посмотреть, есть ли двоеточие в последнем элементе и привет.
Другое дело, что логику парсера можно было бы упростить в разы, приняв концепцию железобетонной структуры key/value/key/value/..., но уже имеем то, что имеем.
# Re: Дополнения к стандарту
ahamai (blackcat, 2) → revoltech – 19:23:45 2024-10-31
> Только за, но здесь почему-то нашлись принципиальные противники этой идеи.
потому что у больших запросов куча проблем и никакого смысла. поэтому в своё время и перешли от них к маленьким. я вообще не понял, какая проблема решается, первоначальный фетч всей текущей сети занимает небольшое время, большой запрос принципиально ничего не изменит. но нагрузка на серверы растёт, однопоточные серверы вообще поставит колом. я не говорю про проблемы обрыва связи. чанками разумного размера качать лучше, чем целым. оптимальным числом эмперическим путём было выбрано 40.
если ты предоставишь бенчмарки, что выгрузка всех сообщений единым блоком хотя бы в 2 раза быстрее, чем чанками по 20 сообщений, тогда это будет интересно. тогда мож и /get вернётся.
ahamai (blackcat, 2) → revoltech – 19:23:45 2024-10-31
> Только за, но здесь почему-то нашлись принципиальные противники этой идеи.
потому что у больших запросов куча проблем и никакого смысла. поэтому в своё время и перешли от них к маленьким. я вообще не понял, какая проблема решается, первоначальный фетч всей текущей сети занимает небольшое время, большой запрос принципиально ничего не изменит. но нагрузка на серверы растёт, однопоточные серверы вообще поставит колом. я не говорю про проблемы обрыва связи. чанками разумного размера качать лучше, чем целым. оптимальным числом эмперическим путём было выбрано 40.
если ты предоставишь бенчмарки, что выгрузка всех сообщений единым блоком хотя бы в 2 раза быстрее, чем чанками по 20 сообщений, тогда это будет интересно. тогда мож и /get вернётся.
# Разбор idec №2
ahamai (blackcat, 2) → All – 19:18:59 2024-10-31
Во-первых, изначально у меня была ошибка, ?sf не прозрачна, её нельзя добавить вообще везде. Потому что есть php-ноды, и там должно быть &. Это, конечно, может задаватся в схеме, и это с точки зрения проектирования куда лучше, чем idec, но это не прозрачная замена, про php ноды я забыл.
Во-вторых, про схемы и проектирование было в прошлом сообщении в этой эхе. Если уже развивать схему, то зачем лезть в уже устоявшийся формат, нарушать его примитивность и топорность: примитивность реализации, примитивность самого формата. Зачем /u/e переюзывать?
Нормальным решением было бы завести свой неймспейс. Тем более, сеть это уже дважды проходила, сначала были /e и /m, но это было медленно и печально, запрос вещь дорогая, на самом деле даже дороже, чем лишний трафик. Потом была /z, потом была /u. И по урлу в конфиге указывалось, по какому протоколу работать. Точно так же можно было сделать и при развитии сети, какой-нибудь /r или /x, всё вынести в этот неймспейс. В случае чего (давайте представим этот дивный мир, где с /u/e ничего не сделали, он всё так же примитивен, как и был изначально) можно даже эмулировать старый интерфейс с неймспейсами /x/e и /x/m, если в старый клиент пропишут новую схему.
И уж если планируются расширения, совершенно точно не надо вешать какие-то костыли, чтобы вопрос "а как задать срез для каждой эхи" не имел ответа.
Про key/value. У босфора был такой интерфейс, /bb/key1/value1/key2/value2. Это было удобно сначала парсить в словарик, а потом с этим словариком работать, минимумом кода достигались красивые вещи, можно было делать разные запросы. Если что-то расширяешь, нужно сразу делать формат, который можно расширять, но который при этом фалбакается, если расширение не поддерживается. Зачем нагромождение ненужных сущностей, которые потом надо ещё прописывать? Когда можно сделать единый урл, единый словарик, а любой фильтр прописывать ровно одной строкой кода, и те системы, которые его не поддерживают, просто не будут по этому критерию фильтровать.
/u/m и /u/e это к тому, что это просто то, что осталось фундаментом, когда всё остальное было удалено для простоты. Тут кое-кто :) пытается переизобрести z/get, который был удалён из-за повышенной нагрузки на сервер, /u/e и /u/m это необходимый самодостаточный минимум, который вообще не должен меняться. А расширения - это то, что должно иметь возможность расширяться, а не хардкодиться в нескольких урлах, и что самое ужасное, при этом изменяя поведение базовых.
Я вообще не понял, к чему были эти изменения idec? Чтобы через 10 лет переизобрести их заново, потому что стандарт, предназначеный для расширения, оказывается не умеет расширяться? Это плохой дизайн. /u/e и /u/m при этом своей актуальности не утратили.
ahamai (blackcat, 2) → All – 19:18:59 2024-10-31
Во-первых, изначально у меня была ошибка, ?sf не прозрачна, её нельзя добавить вообще везде. Потому что есть php-ноды, и там должно быть &. Это, конечно, может задаватся в схеме, и это с точки зрения проектирования куда лучше, чем idec, но это не прозрачная замена, про php ноды я забыл.
Во-вторых, про схемы и проектирование было в прошлом сообщении в этой эхе. Если уже развивать схему, то зачем лезть в уже устоявшийся формат, нарушать его примитивность и топорность: примитивность реализации, примитивность самого формата. Зачем /u/e переюзывать?
Нормальным решением было бы завести свой неймспейс. Тем более, сеть это уже дважды проходила, сначала были /e и /m, но это было медленно и печально, запрос вещь дорогая, на самом деле даже дороже, чем лишний трафик. Потом была /z, потом была /u. И по урлу в конфиге указывалось, по какому протоколу работать. Точно так же можно было сделать и при развитии сети, какой-нибудь /r или /x, всё вынести в этот неймспейс. В случае чего (давайте представим этот дивный мир, где с /u/e ничего не сделали, он всё так же примитивен, как и был изначально) можно даже эмулировать старый интерфейс с неймспейсами /x/e и /x/m, если в старый клиент пропишут новую схему.
И уж если планируются расширения, совершенно точно не надо вешать какие-то костыли, чтобы вопрос "а как задать срез для каждой эхи" не имел ответа.
Про key/value. У босфора был такой интерфейс, /bb/key1/value1/key2/value2. Это было удобно сначала парсить в словарик, а потом с этим словариком работать, минимумом кода достигались красивые вещи, можно было делать разные запросы. Если что-то расширяешь, нужно сразу делать формат, который можно расширять, но который при этом фалбакается, если расширение не поддерживается. Зачем нагромождение ненужных сущностей, которые потом надо ещё прописывать? Когда можно сделать единый урл, единый словарик, а любой фильтр прописывать ровно одной строкой кода, и те системы, которые его не поддерживают, просто не будут по этому критерию фильтровать.
/u/m и /u/e это к тому, что это просто то, что осталось фундаментом, когда всё остальное было удалено для простоты. Тут кое-кто :) пытается переизобрести z/get, который был удалён из-за повышенной нагрузки на сервер, /u/e и /u/m это необходимый самодостаточный минимум, который вообще не должен меняться. А расширения - это то, что должно иметь возможность расширяться, а не хардкодиться в нескольких урлах, и что самое ужасное, при этом изменяя поведение базовых.
Я вообще не понял, к чему были эти изменения idec? Чтобы через 10 лет переизобрести их заново, потому что стандарт, предназначеный для расширения, оказывается не умеет расширяться? Это плохой дизайн. /u/e и /u/m при этом своей актуальности не утратили.
# Re: Дополнения к стандарту
revoltech (spnet, 4) → Andrew Lobanov – 19:21:27 2024-10-31
AL> 10+ лет качаем по 40. Полёт нормальный.
Ну а мне откуда было это знать? Нигде о 40 не было написано. А tgi уже на 13 посылает куда подальше, например.
AL> Хорошо. Я укажу в стандарте 40. Все, кто качает больше или предоставляют меньше, не соблюдают стандарт.
Ну вот так бы сразу.
revoltech (spnet, 4) → Andrew Lobanov – 19:21:27 2024-10-31
AL> 10+ лет качаем по 40. Полёт нормальный.
Ну а мне откуда было это знать? Нигде о 40 не было написано. А tgi уже на 13 посылает куда подальше, например.
AL> Хорошо. Я укажу в стандарте 40. Все, кто качает больше или предоставляют меньше, не соблюдают стандарт.
Ну вот так бы сразу.
# Re: Дополнения к стандарту
ahamai (blackcat, 2) → hugeping – 18:59:20 2024-10-31
> Например, в данном случае, в один запрос запиханы разные лимиты слайсов для разных эх. Зачем?
Так это была изначальная идея - для экономии трафика. я всегда думал, что оно именно так и сделано, там 100 rss сообщений за час их и забрали, там 1 за неделю. а так это какая-то полумера, ни туда ни сюда.
> Потом, Рома трясёт своим ?sf=hash - как замену слайсов.
Приехали. Я не использую ?sf. Я не собираюсь использовать ?sf. Оно создано ровно для одного случая, работы в условиях медленного интернета. Для чего, как заявлялось, и делался idec. И, в отличие от idec, он делает ровно то, что от него просят, даёт одним запросом ровно то, что нужно, минимальный объём сообщений.
> На самом деле этот sf=hash при своей красоте, всё-таки, хуже слайсов. Во первых, даже с хешем надо делать запрос внахлёст с запасом (не забываем про то, что порядок сообщений на ноде может не совпадать с нашим)
Не надо так делать. В 99% случаев запрос вернёт ровно то, что от него хотят. В остальных случаях, скорее всего, поможет только полный фетч.
> и нам все равно придётся самим на своей станции находить n сообщение от конца в эхе и брать затем его хеш чтобы сформировать запрос. Те же слайсы, вид сбоку.
Только все эхи опрашиваются одним запросом, и с нужным количеством сообщений.
>> Читать далее
ahamai (blackcat, 2) → hugeping – 18:59:20 2024-10-31
> Например, в данном случае, в один запрос запиханы разные лимиты слайсов для разных эх. Зачем?
Так это была изначальная идея - для экономии трафика. я всегда думал, что оно именно так и сделано, там 100 rss сообщений за час их и забрали, там 1 за неделю. а так это какая-то полумера, ни туда ни сюда.
> Потом, Рома трясёт своим ?sf=hash - как замену слайсов.
Приехали. Я не использую ?sf. Я не собираюсь использовать ?sf. Оно создано ровно для одного случая, работы в условиях медленного интернета. Для чего, как заявлялось, и делался idec. И, в отличие от idec, он делает ровно то, что от него просят, даёт одним запросом ровно то, что нужно, минимальный объём сообщений.
> На самом деле этот sf=hash при своей красоте, всё-таки, хуже слайсов. Во первых, даже с хешем надо делать запрос внахлёст с запасом (не забываем про то, что порядок сообщений на ноде может не совпадать с нашим)
Не надо так делать. В 99% случаев запрос вернёт ровно то, что от него хотят. В остальных случаях, скорее всего, поможет только полный фетч.
> и нам все равно придётся самим на своей станции находить n сообщение от конца в эхе и брать затем его хеш чтобы сформировать запрос. Те же слайсы, вид сбоку.
Только все эхи опрашиваются одним запросом, и с нужным количеством сообщений.
>> Читать далее
# Re: Разбор idec
ahamai (blackcat, 2) → Andrew Lobanov – 18:34:26 2024-10-31
> Ты хочешь в срезе получить нецелое количество сообщений? Зачем тебе точка в срезе? Типа, -12.5:12.5?
если точка в срезе, то старый софт будет воспринимать это не как непонятный msgid и падать с ошибкой его запросить, а как пустую эху и просто игнорировать. двоеточие можно уронить, 12..12. или нарисовать ху^W самолётик 12.:.12. это мелочи, но мелочи это именно то, что отделяет плохой дизайн от хорошего, когда всё предусмотрено заранее.
ahamai (blackcat, 2) → Andrew Lobanov – 18:34:26 2024-10-31
> Ты хочешь в срезе получить нецелое количество сообщений? Зачем тебе точка в срезе? Типа, -12.5:12.5?
если точка в срезе, то старый софт будет воспринимать это не как непонятный msgid и падать с ошибкой его запросить, а как пустую эху и просто игнорировать. двоеточие можно уронить, 12..12. или нарисовать ху^W самолётик 12.:.12. это мелочи, но мелочи это именно то, что отделяет плохой дизайн от хорошего, когда всё предусмотрено заранее.
# Re: Дополнения к стандарту
Andrew Lobanov (tavern,1) → revoltech – 18:38:25 2024-10-31
shaos>> И наверное надо метод POST добавить (я у себя добавлю)
revoltech> Только за, но здесь почему-то нашлись принципиальные противники этой идеи.
Эта идея решает примерно - проблем. Так зачем?
Могу добавить, оставив упоминание про потолок в 40 айдишников на запрос.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → revoltech – 18:38:25 2024-10-31
shaos>> И наверное надо метод POST добавить (я у себя добавлю)
revoltech> Только за, но здесь почему-то нашлись принципиальные противники этой идеи.
Эта идея решает примерно - проблем. Так зачем?
Могу добавить, оставив упоминание про потолок в 40 айдишников на запрос.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: Дополнения к стандарту
Andrew Lobanov (tavern,1) → revoltech – 18:36:33 2024-10-31
hugeping>> Всё-таки, это не аксиома. Тут мы зависим от внешнего фактора.
revoltech> Не аксиома, но вполне разумное значение по умолчанию. Сисопа проще пнуть на документальном уровне и пусть объясняет, почему приём 380 айдишников в /u/m для него проблема.
Хорошо. Я укажу в стандарте 40. Все, кто качает больше или предоставляют меньше, не соблюдают стандарт.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → revoltech – 18:36:33 2024-10-31
hugeping>> Всё-таки, это не аксиома. Тут мы зависим от внешнего фактора.
revoltech> Не аксиома, но вполне разумное значение по умолчанию. Сисопа проще пнуть на документальном уровне и пусть объясняет, почему приём 380 айдишников в /u/m для него проблема.
Хорошо. Я укажу в стандарте 40. Все, кто качает больше или предоставляют меньше, не соблюдают стандарт.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: Дополнения к стандарту
Andrew Lobanov (tavern,1) → revoltech – 18:36:33 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?
Это уже прописано в стандарте. Только почему это должно быть прописано в стандарте IDEC?
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → revoltech – 18:36:33 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?
Это уже прописано в стандарте. Только почему это должно быть прописано в стандарте IDEC?
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: Дополнения к стандарту
Andrew Lobanov (tavern,1) → revoltech – 18:36:32 2024-10-31
AL>> Пинать сисопа своего аплинка. Потому что такие короткие урлы это издевательство.
revoltech> Хорошо. Какие — не издевательство? Сколько айдишников скачивать по умолчанию? Где проходит граница между «слишком жирно» и «пора пинать сисопа»?
10+ лет качаем по 40. Полёт нормальный. Зачем выдумывать себе трудности? Чтобы героически их преодолевать?
revoltech> Может, в стандарте хотя бы рекомендованное число указать в таком случае? Опытным путём вот выяснилось, что апачу 389 айдишников можно скормить в /u/m на дефолтных настройках. А на spline-online сколько, например?
Настройки веб-сервера выходят за рамки стандарта.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → revoltech – 18:36:32 2024-10-31
AL>> Пинать сисопа своего аплинка. Потому что такие короткие урлы это издевательство.
revoltech> Хорошо. Какие — не издевательство? Сколько айдишников скачивать по умолчанию? Где проходит граница между «слишком жирно» и «пора пинать сисопа»?
10+ лет качаем по 40. Полёт нормальный. Зачем выдумывать себе трудности? Чтобы героически их преодолевать?
revoltech> Может, в стандарте хотя бы рекомендованное число указать в таком случае? Опытным путём вот выяснилось, что апачу 389 айдишников можно скормить в /u/m на дефолтных настройках. А на spline-online сколько, например?
Настройки веб-сервера выходят за рамки стандарта.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: Разбор idec
ahamai (blackcat, 2) → Andrew Lobanov – 18:30:25 2024-10-31
> Откуда оно там возьмётся?
http://ii.blcat.ru/u/e/blcat.test/-100:100
ahamai (blackcat, 2) → Andrew Lobanov – 18:30:25 2024-10-31
> Откуда оно там возьмётся?
http://ii.blcat.ru/u/e/blcat.test/-100:100
# Re: Дополнения к стандарту
ahamai (blackcat, 2) → revoltech – 18:26:11 2024-10-31
Большие запросы вообще не нужны. Во-первых, они не нужны в принципе, я вообще не вижу разницы между запросами по 10 и по 40 сообщений, я и так и так легко выкачиваю всю сеть. Во-вторых, это ставит колом однопоточные серверы. Я бы запросы более 40 мессаг за раз расценивал бы как XAB.
ahamai (blackcat, 2) → revoltech – 18:26:11 2024-10-31
Большие запросы вообще не нужны. Во-первых, они не нужны в принципе, я вообще не вижу разницы между запросами по 10 и по 40 сообщений, я и так и так легко выкачиваю всю сеть. Во-вторых, это ставит колом однопоточные серверы. Я бы запросы более 40 мессаг за раз расценивал бы как XAB.
# Re: Дополнения к стандарту
revoltech (spnet, 4) → shaos – 17:05:42 2024-10-31
shaos> Рекомендовать 32 т.к. оно вообще не через http-сервер может идти, а через самописный (кстати bottle.py какое ограничение имеет?)
Да у самописных вообще ограничений нет обычно.
revoltech (spnet, 4) → shaos – 17:05:42 2024-10-31
shaos> Рекомендовать 32 т.к. оно вообще не через http-сервер может идти, а через самописный (кстати bottle.py какое ограничение имеет?)
Да у самописных вообще ограничений нет обычно.
# Re: Дополнения к стандарту
shaos (spnet, 2) → shaos – 17:03:50 2024-10-31
Рекомендовать 32 т.к. оно вообще не через http-сервер может идти, а через самописный (кстати bottle.py какое ограничение имеет?)
shaos (spnet, 2) → shaos – 17:03:50 2024-10-31
Рекомендовать 32 т.к. оно вообще не через http-сервер может идти, а через самописный (кстати bottle.py какое ограничение имеет?)
# Re: Дополнения к стандарту
revoltech (spnet, 4) → shaos – 16:52:05 2024-10-31
shaos> Лучше написать не больше 380 т.к. вебсервер может такое не пережувать
Ну я о том же, можно сказать, что 380 — максимум, который нужно поддерживать, а дальше уже на усмотрение владельца сервера.
shaos> И наверное надо метод POST добавить (я у себя добавлю)
Только за, но здесь почему-то нашлись принципиальные противники этой идеи.
revoltech (spnet, 4) → shaos – 16:52:05 2024-10-31
shaos> Лучше написать не больше 380 т.к. вебсервер может такое не пережувать
Ну я о том же, можно сказать, что 380 — максимум, который нужно поддерживать, а дальше уже на усмотрение владельца сервера.
shaos> И наверное надо метод POST добавить (я у себя добавлю)
Только за, но здесь почему-то нашлись принципиальные противники этой идеи.
# Re: Дополнения к стандарту
shaos (spnet, 2) → hugeping – 16:49:59 2024-10-31
Рекомендовать 32, но указать, что некоторые вебсервера могу принять до 380
shaos (spnet, 2) → hugeping – 16:49:59 2024-10-31
Рекомендовать 32, но указать, что некоторые вебсервера могу принять до 380
# Re: Дополнения к стандарту
shaos (spnet, 2) → revoltech – 16:48:10 2024-10-31
Лучше написать не больше 380 т.к. вебсервер может такое не пережувать
И наверное надо метод POST добавить (я у себя добавлю)
shaos (spnet, 2) → revoltech – 16:48:10 2024-10-31
Лучше написать не больше 380 т.к. вебсервер может такое не пережувать
И наверное надо метод POST добавить (я у себя добавлю)
# Re: Дополнения к стандарту
shaos (spnet, 2) → tuple – 16:46:09 2024-10-31
> tgi же неоднократно просил считать владелец станцией экспериментов и не фетчиться с неё.
Ну может кого и просил, но мы с ним в сентябре 2022 года по е-мейлу договорились взаимно фетчить idec.talks и zx.spectrum, а потом я ещё bot.habr.rss у него начал забирать.
shaos (spnet, 2) → tuple – 16:46:09 2024-10-31
> tgi же неоднократно просил считать владелец станцией экспериментов и не фетчиться с неё.
Ну может кого и просил, но мы с ним в сентябре 2022 года по е-мейлу договорились взаимно фетчить idec.talks и zx.spectrum, а потом я ещё bot.habr.rss у него начал забирать.
# Re: Разбор idec
shaos (spnet, 2) → Andrew Lobanov – 16:37:55 2024-10-31
Ну это веб-морда того же ii-php и шлёт :)
Балин!!! Точно!!! Спасибо!!!
shaos (spnet, 2) → Andrew Lobanov – 16:37:55 2024-10-31
Ну это веб-морда того же ii-php и шлёт :)
Балин!!! Точно!!! Спасибо!!!
# Re: Тест скорости фетча (+потеряшки)
shaos (spnet, 2) → hugeping – 16:34:11 2024-10-31
Было несколько сообщение с 19-символьными msgid - я раньше писал про это.
Их можно вернуть в строй, добавив нолик в конце и поправив repto, где на них ссылаются.
shaos (spnet, 2) → hugeping – 16:34:11 2024-10-31
Было несколько сообщение с 19-символьными msgid - я раньше писал про это.
Их можно вернуть в строй, добавив нолик в конце и поправив repto, где на них ссылаются.