> - сам idec -- прост как валенок и выполняет свою работу (при всей технологичности ГК11, мне кажется, idec обладает большей простотой);

Ну, смотря что понимать под простотой. А вообще, я от ii никогда не отказывался, его реализация мне всегда нравилась. И, фактически, ii и ГК11 это одно и то же (это не потому, что это хорошо, а потому, что я ничего другого изобретать не умею - всегда одно и то же получается).

Просто ii стал слишком идеален. :) Меньше всего я люблю писать код. А больше всего - удалять код. Когда удаляешь огромный блок, и ничего от этого не ломается - это то самое прекрасное чувство, когда мир становится лучше. И в один момент я вдруг понял, что уже нечего больше упрощать. Как в том анекдоте - *у руководства Газпрома закончились мечты*.

Тогда я решил изменить подход. ГК11 гораздо проще для клиентов, потому что можно многие вещи делать просто правильными запросами. Но он сложнее в серверах - как минимум, он просто обязан ориентироваться на выборки базы данных. Что даёт дополнительные возможности.

Например, в ii идёт двойная запись. Есть файл эхи, где перечислены msgid, и есть файл msgid, где есть указание эхи (причём изначально это задумано только для того, чтобы можно было *перебилдить индекс*, то есть пересобрать файл эхи). При этом возможна ситуация, что файл есть на диске, но его нет в списке эхи. Или, наоборот, есть в списке, но самого файла уже нет. Кроме того, на заре времён люди лихо переименовывали эхи, а внутри указатель оставался старым - поэтому никакой софт не доверяет тому, что указано в параметре *эха* (я уж молчу про то, что в первых версиях был сервер-сайд-кроспост, то есть эх могло быть сразу несколько - и такие сообщения, наверное, до сих пор можно найти в архиве сети).

В новом протоколе же это невозможно. И там всегда можно ориентироваться на то, что и сообщение из списка эхи, и тэг эхи в сообщении - это одно и то же. Когда ты давно не собирал почту, тебе придут сначала 200 сообщений из эхи А, затем 200 из эхи Б. И если в старом протоколе ты обязан так получать, разбирая эху, то в новом ты получаешь все сообщения одним потоком, не разделяя бандл на *указатель эхи* и *код сообщения*, общим потоком сообщений и именно в том порядке, как они пришли, а имя эхи вычленяешь из сообщения. В общем, его реализация и постоянное упрощение позволили избавить сам сервер от многих проблем. И теперь, фактически, он стал предельно прост, и ничего не мешало заменить его на *ii без циферок*, т.е. на idec (в базовой его реализации). Но всё равно, мой 51talk к твоей станции запрашивает списки не через list.txt, а через /discover :) Но в остальном сейчас этот протокол для обмена и не нужен, старого хватит - главное, что его реализация помогла решить разные проблемы, и даже в рамках текущего стандарта стало возможным делать многие вещи. А /bb/ (как и json и другие api) хорошо подходит для самописного софта, которому не обязательно быть стандартным (вот клиенты или софт обработки для протокола /bb/ не стоит писать ни в коем случае! ибо любой idec-софт совместим с любой гк11-станцией и idec-станцией, а гк11-софт - только с гк11-станцией. а самописный одноразовый софт, благодаря развитому api, писать становится проще).

Но в любом случае это вопрос нюансов, а протоколы ii/idec и /bb/-запросы - это практически одно и то же. Просто idec давно стандартизован и его url-ы более привычны для клиентов.