Рекомендовать 32, но указать, что некоторые вебсервера могу принять до 380

shaos> Лучше написать не больше 380 т.к. вебсервер может такое не пережувать

Ну я о том же, можно сказать, что 380 — максимум, который нужно поддерживать, а дальше уже на усмотрение владельца сервера.

shaos> И наверное надо метод POST добавить (я у себя добавлю)

Только за, но здесь почему-то нашлись принципиальные противники этой идеи.

Рекомендовать 32 т.к. оно вообще не через http-сервер может идти, а через самописный (кстати bottle.py какое ограничение имеет?)

shaos> Рекомендовать 32 т.к. оно вообще не через http-сервер может идти, а через самописный (кстати bottle.py какое ограничение имеет?)

Да у самописных вообще ограничений нет обычно.

Ну это как написать…

AL>> Пинать сисопа своего аплинка. Потому что такие короткие урлы это издевательство.
revoltech> Хорошо. Какие — не издевательство? Сколько айдишников скачивать по умолчанию? Где проходит граница между «слишком жирно» и «пора пинать сисопа»?

10+ лет качаем по 40. Полёт нормальный. Зачем выдумывать себе трудности? Чтобы героически их преодолевать?

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.
revoltech> Так, может, тогда и в стандарте прописать |(8000 - 5) / 21| = 380 айдишников рекомендованным максимумом для отдачи через /u/m?

Это уже прописано в стандарте. Только почему это должно быть прописано в стандарте IDEC?

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

hugeping>> Всё-таки, это не аксиома. Тут мы зависим от внешнего фактора.
revoltech> Не аксиома, но вполне разумное значение по умолчанию. Сисопа проще пнуть на документальном уровне и пусть объясняет, почему приём 380 айдишников в /u/m для него проблема.

Хорошо. Я укажу в стандарте 40. Все, кто качает больше или предоставляют меньше, не соблюдают стандарт.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

shaos>> И наверное надо метод POST добавить (я у себя добавлю)
revoltech> Только за, но здесь почему-то нашлись принципиальные противники этой идеи.

Эта идея решает примерно - проблем. Так зачем?

Могу добавить, оставив упоминание про потолок в 40 айдишников на запрос.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

Большие запросы вообще не нужны. Во-первых, они не нужны в принципе, я вообще не вижу разницы между запросами по 10 и по 40 сообщений, я и так и так легко выкачиваю всю сеть. Во-вторых, это ставит колом однопоточные серверы. Я бы запросы более 40 мессаг за раз расценивал бы как XAB.

> Откуда оно там возьмётся?

http://ii.blcat.ru/u/e/blcat.test/-100:100

> Ты хочешь в срезе получить нецелое количество сообщений? Зачем тебе точка в срезе? Типа, -12.5:12.5?

если точка в срезе, то старый софт будет воспринимать это не как непонятный msgid и падать с ошибкой его запросить, а как пустую эху и просто игнорировать. двоеточие можно уронить, 12..12. или нарисовать ху^W самолётик 12.:.12. это мелочи, но мелочи это именно то, что отделяет плохой дизайн от хорошего, когда всё предусмотрено заранее.

> Например, в данном случае, в один запрос запиханы разные лимиты слайсов для разных эх. Зачем?

Так это была изначальная идея - для экономии трафика. я всегда думал, что оно именно так и сделано, там 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. пока будет опциональным. пусть внедряется. :)
****

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

AL> 10+ лет качаем по 40. Полёт нормальный.

Ну а мне откуда было это знать? Нигде о 40 не было написано. А tgi уже на 13 посылает куда подальше, например.

AL> Хорошо. Я укажу в стандарте 40. Все, кто качает больше или предоставляют меньше, не соблюдают стандарт.

Ну вот так бы сразу.

Во-первых, изначально у меня была ошибка, ?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 при этом своей актуальности не утратили.

> Только за, но здесь почему-то нашлись принципиальные противники этой идеи.

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

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

Уважаемый, я вот вроде тебя и понимаю, и не понимаю одновременно. Например, я пришёл сюда совсем недавно. Старую ii-документацию в этих ваших интернетах уже не сыскать, все старые сайты протухли. Откуда мне было знать про «эмпирическим путём найденный» лимит в 40 мессаг, про /z/get и прочие босфоры?

ahamai> И уж если планируются расширения, совершенно точно не надо вешать какие-то костыли, чтобы вопрос "а как задать срез для каждой эхи" не имел ответа.

Здесь согласен.

ahamai> Про key/value. У босфора был такой интерфейс, /bb/key1/value1/key2/value2. Это было удобно сначала парсить в словарик, а потом с этим словариком работать, минимумом кода достигались красивые вещи, можно было делать разные запросы. Если что-то расширяешь, нужно сразу делать формат, который можно расширять, но который при этом фалбакается, если расширение не поддерживается. Зачем нагромождение ненужных сущностей, которые потом надо ещё прописывать? Когда можно сделать единый урл, единый словарик, а любой фильтр прописывать ровно одной строкой кода, и те системы, которые его не поддерживают, просто не будут по этому критерию фильтровать.

И здесь согласен.

ahamai> и что самое ужасное, при этом изменяя поведение базовых.

А здесь не согласен. Здесь прав товарищ AL, который говорит, что поведение остаётся прежним, нужно только подкорректировать логику парсера. Ну, типа, старые /u/e никуда не деваются, нужно только посмотреть, есть ли двоеточие в последнем элементе и привет.

Другое дело, что логику парсера можно было бы упростить в разы, приняв концепцию железобетонной структуры key/value/key/value/..., но уже имеем то, что имеем.

ahamai> если ты предоставишь бенчмарки, что выгрузка всех сообщений единым блоком хотя бы в 2 раза быстрее, чем чанками по 20 сообщений, тогда это будет интересно. тогда мож и /get вернётся.

Это зависит от местоположения клиента и ноды. В стерильных тестовых условиях, может, и не вдвое быстрее будет. А вот в реальных время установки TCP/TLS-соединения тоже существенно добавляет к общей картине. Могу на днях замерять перефетч с shaos-а после уменьшения чанка с 389 сообщений до 40. Или с ping после уменьшения с 10000 до 40... Если интересно.

> А здесь не согласен. Здесь прав товарищ AL, который говорит, что поведение остаётся прежним, нужно только подкорректировать логику парсера. Ну, типа, старые /u/e никуда не деваются, нужно только посмотреть, есть ли двоеточие в последнем элементе и привет.

это полностью ломает единость формата. /u/e должна быть везде, и должна реализовываться в 3 строках. у неё не должно быть расхождений, не надо в /u/e добавлять парсеры, /u/e должна быть единой и быть везде. все остальные расширения - отдельно.