хотя нет, чёт там всего много :)

кстати, я нашёл в инете сырцы bosfor. поменять размер msgid с 11 до 20 и добавить обязательные точки в эхах - и будет вообще полноценная прозрачная замена, полностью совместимая с ii и при этом обладающая развитым api

/u/e и /u/m захаркожены в урлах именно потому что они топорные, примитивные и неизменяемые. у босфора был свой неймспейс /bb, который решал все задачи и слайсов, и ...яйсов. делай выборку так, как тебе хочется, делай проверку так, как тебе хочется. кода каждая проверка занимала примерно одну-две строчки. Поэтому любое расширение добавить дело было пары минут. И это расширение даже не надо делать мейнстримным, это может быть расширение, которое служит чисто для удобство обмена двух нод (как твой /h/x). И вообще ничего нигде не ломает и не хачит by design. Единый урл, который собирает все key/value в словарик, примерно как тэги в первой строке каждого ii сообщения типа repto, которые тоже позволяют развивать формат, добавляя свои тэги, которые не понимающие их станции игнорят (см. elp, там были тэги topicid и tags, и elp тоже отлично гейтовался в ii)

и да, если ты делаешь расширяемый формат, то делай его РАСШИРЯЕМЫМ. потому что кроме x:y это расширение не умеет, и добавить туда, не делая очередные псевдозаменители эх. Типа /эха/x;y/эха/x:y

bosfor имел полноценное key/value api, и при простой внутренней структуре позволял делать крутые вещи, типа выборок "дай мне сообщение с такого-то таймстампа по такой-то таймстамп", хоть в конкретных эхах, хоть во всех, хоть с выборкой по юзеру. и при этом был в обе стороны полностью совместим с ii. можно было просто сделать api, и там кто хочет в серверах, кто хочет в клиентах, использует хоть выборку по сообщениям, хоть выборку по msgid, а клиент/фетчер уже схемой в конфиге указывает, что и где он берёт. отсутствие нужного фильтра просто не фильтрует по этому параметру. у босфора просто ни одного клиента не было, чтобы это где-то использовать :) но когда люди сами пишут клиентов - это самая разумная схема. нет, надо наделать проверок в клиенте, проверок в сервере, чтобы хакнуть /u/e, и теперь у нас два /u/e

Многие проблемы решаются кодом, а ещё большие её отсутствием. Плохой дизайн нельзя исправить кодом, или стандартами. Как пример это e-mail/smtp.

> Если нет проверки на то, что тебе не подсунули мусор, то это неработоспособное решение - как POC для запуска в песочнице для ограниченного круга лиц - годится, а для реальных применений в массах - нет…

ЕСЛИ МУСОР - ПАДАЙ. Не надо разбирать мусор. Топология сети такая, итить. Ты качаешь с доверенных узлов по предварительной договорённости. Формат бандла определён. Если оттуда летит мусор, то это уже красный код, не надо с него качать и не надо ничего разбирать, надо снимать с фетча.

Какое, итить, неработоспособное решение, если оно работает. Сколько раз повторять, что /u/e/ это базовый фалбак и он должен быть простым и легко воспроизводимым, нигде не должно быть проверки в коде и в стандарте. Как работает твой конкретный фетчер, по барабану. Есть базовая реализация, эталонная. И она должна быть максимально простая. И она должна быть одна.

Это базовый вопрос - НАХРЕНА ВЫ ЛЕЗЕТЕ В /U/E, ЕСЛИ ВЫ ТУПО ДАЖЕ НЕ ПОНИМАЕТЕ, ЧТО ЭТО И ЗАЧЕМ ЭТО НУЖНО???

ну я читаю такую ахинею

> Если нет проверки на то, что тебе не подсунули мусор, то это неработоспособное решение

и вижу люди тупо не понимают, о чём это вообще.

> а для реальных применений в массах - нет…

для каких млять применений в каких млять массах. ii это реализация строго конкретной задачи. основным критерием этой задачи является максимальная простота. НИКТО, НИКТО МЛяТЬ В ЦЕЛОМ СВЕТЕ НЕ МЕШАЕТ ТЕБЕ НАВЕШИВАТЬ СВОИ НАВОРОТЫ. Ну оставь ты млять в покое /u/e, это лингва франка, это база, это долгими бессонными ночами вытачивалось, чтобы удалить всё лишнее и оставить только базу, из которой можно свинтить что угодно, хоть босфор, хоть улисс - и никто при этом не трогал /u/e. Когда человечество вымрет и останутся только ветки и палки, чтобы можно было быстро собрать /u/e, как базовый компонент. И ПОЭТОМУ ОН МЛЯТЬ ДОЛЖЕН БЫТЬ ОФОРМЛЕН, ПРОСТ И ОДНОЗНАЧЕН, чтобы любая макака могла написать его реализацию. Любая. На любом языке. С любым млять навыком. Не мусор собирала.

И это млять не POC. Это и есть млять сама концепция сети. Нахрена переписывать базовый класс, наследуйся от него и потом пиши, как хочешь. А основные 4 стержня, которые работают в любых, любых млять условиях, они для того и сделаны такими простыми чтобы быть такими простыми. Без проверок, х..рок и прочей хрени. Обмен между нодами регламентируется ТОЛЬКО самими нодами. Могут хоть через git обмениваться и индексы по timestamp генерировать, это изначально была валидная версия обмена. Но помимо этого должна быть база, которая должна работать ВСЕГДА, ВЕЗДЕ, она должна быть МАКСИМАЛЬНО ПРОСТОЙ и МАКСИМАЛЬНО ВОСПРОИЗВОДИМОЙ. Поверх этого уже какие хошь расширения, это вообще пофиг, лишь бы клиент и сервер поддерживали. Но когда есть два стандарта на работу /u/e (один мой, другой неправильный (ц)) - это уже маразм.

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

+++ memo:marazm

> тут нет никаких "что-то ещё", либо эха либо msgid.

… либо мусор

Если нет проверки на то, что тебе не подсунули мусор, то это неработоспособное решение - как POC для запуска в песочнице для ограниченного круга лиц - годится, а для реальных применений в массах - нет…

даже list.txt подстраивается

http://ii.blcat.ru/lim/100/list.txt

или пойдёт. у меня уже столько расхождений между текущей станцией и 0.7, что надо на 0.7 переползать и уже в неё изменения вносить. в общем, вся хрень типа девочек-аватарок и advent удаляется, я перееду на 0.7

Я вообще не про это. Я про то, что не надо было трогать протокол, который для трогания совсем не предназначался. В чём проблема была вместо проверки x/feautures всяких просто использовать новый, а при отказе - фэлбекаться? Ну самый же очевидный дизайн. Зачем там, где всё было предельно просто, зачем-то совершенно ненужно это усложнять?

> Просто парсить надо будет вручную

это не есть прозрачная замена. прозрачная замена, это когда ты в любом клиенте просто прописываешь этот url вместо нужного, и ровно ничего не меняется кроме того случая, когда фильтр срабатывает, независимо от того, знает ли нода что-то или нет. если добавлять везде ?sf, то нода с запросом ?q=, ничего не знающая о ?sf, на запросе брякнется

вот /lim/ совместима с любыми существующими клиентами, просто меняешь url в конфиге и всё.

> Так она и реализуется в 3-5 строках, если нормальные ЯП юзать. И поведение от запроса со слайсом на ноду, которая слайсы не реализует, меняться не будет: этот последний компонент просто не является валидным именем эхи. Нода, которая не умеет слайсить, должна его просто отбросить. Если она так не делает, чини реализацию.

1.

> ВЕСЬ ЗАПРОС СПИСОК ЭХ
> ПОЛУЧИЛИ СПИСКИ
> ЕСЛИ ЕСТЬ ЛИМИТ, УСТАНОВИЛИ
> становится
> ПОЛУЧИЛИ СПИСОК ЭХ
> ПРОВЕРИЛИ ПОСЛЕДНЮЮ
> ЕСЛИ ЭТО СРЕЗ, ТО РАСПАРСИЛИ СРЕЗ
> СОХРАНИЛИ ЛИМИТ
> УДАЛИЛИ ПОСЛЕДНЮЮ ЭХУ
> ПОЛУЧИЛИ СПИСКИ
> УСТАНОВИЛИ ЛИМИТ, ЕСЛИ ЕСТЬ

2. речь не о нормальных языках, речь о том, чтобы реализовать это в 3х шагах даже на posix shell и чтобы это было просто. ну не нужны там они нахрен, есть куча других неймспейсов, там пусть будут парсеры, шмарсеры и прочее. в чём проблема, запустил свой парсер, который можно расширять хоть до посинения, нету его - фалбакнулся. а "ну легко же реализовать" - это не дизайн. теперь туда включается и критерий "нужны нормальные языки". а сеть планировалась работать в аномальных условиях, хоть на дискете с openbsd. и для этого все протоколы простые. и не надо их усложнять, они не для того делались.

3.
ii.dev.2014
1396262024
51t
lenina,1
ksa242
Re: Адреса msgfrom/msgto
...
список - либо /e

номер
номер
номер

либо /z/e (у эхи есть символ ".", у номера сообщения - нет)

эха
номер
номер
номер
эха
номер
номер
номер
...

тут нет никаких "что-то ещё", либо эха либо msgid. когда "надо фильтровать", "надо разбирать последнюю эху" или что-то ещё надо, это вообще не про /u/e. там месяцы ушли, чтобы вырезать всё, что можно вырезать, чтобы прийти к такому предельно простому виду. этот протокол вообще не про проверки, он про примитивность. расширения должны быть расширениями. я вообще не понимаю, в чём проблема не трогать /u/e? мир перевернётся, если это будет какой-то другой запрос. к тому же, этих запросов был вагон и все в итоге оказались не нужны, на проблему повышенного трафика частично забили. ну сделайте нормальный api, с тем же key/value, расширяемый, позволяющий вольности, зачем лезть в /u/e ломая его единство - этот протокол уже определён, зафиксирован, и будет просто средством фалбака, максимально примитивным и рабочим средством, позволяющим общаться всему со всем. ему не нужны версии, он и так в идеальной стадии.. был

Ну расширенный слайсами /u/e существует уже тоже 10 лет и поддержан кучей клиентов и серверных реализаций - так что проще добавить одну проверку в blcat.ru дабы исключить падучесть и далее сосуществовать в мире и согласии :)

> Во-первых, изначально у меня была ошибка, ?sf не прозрачна, её нельзя добавить вообще везде. Потому что есть php-ноды, и там должно быть &.

Ну я ведь у себя поддержал list.txt?h=1 :)

Просто парсить надо будет вручную

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

Так она и реализуется в 3-5 строках, если нормальные ЯП юзать. И поведение от запроса со слайсом на ноду, которая слайсы не реализует, меняться не будет: этот последний компонент просто не является валидным именем эхи. Нода, которая не умеет слайсить, должна его просто отбросить. Если она так не делает, чини реализацию.

Уже 10 лет у меня можно было получить сообщение по первым 6 символам его msgid. И никогда это не использовалось, хэш запомнить сложно. Поэтому на своей станции (в nastene-07 оно не пойдёт) и пока только через веб интерфейс сделал такой механизм - таглайн мемо. Он добавляет первые 6 символов хэша, а от остального хэша берёт остальные 14.

Если всё пойдёт по плану, то это сообщение будет доступно здесь: http://ii.blcat.ru/memo00

+++ memo:memo00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 при этом своей актуальности не утратили.

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

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

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

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

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

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

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

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. Все, кто качает больше или предоставляют меньше, не соблюдают стандарт.

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

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

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

revoltech> Может, в стандарте хотя бы рекомендованное число указать в таком случае? Опытным путём вот выяснилось, что апачу 389 айдишников можно скормить в /u/m на дефолтных настройках. А на spline-online сколько, например?

Настройки веб-сервера выходят за рамки стандарта.

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

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

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

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

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

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