> 200000 - это смешной размер
> [код]

Выполнение этого скрипта заняло у меня 15 секунд. Плюс заметим, что ПО ii для своих нужд требуется и распарсить файлы, и проводить поиск. Нельзя забывать, что на сервер могут приходить (в перспективе) сотни запросов ежесекундно, так что беспокоиться есть за что.

> замена не подойдёт. во-первых, заменяемый код может уже быть в коде, а во-вторых, внутри кода не должны работать никакие другие парсеры, типа "url в ссылку" и тому подобное.

Хорошо, согласен.

> а так у меня используются msg:// и echo://

Вот хотелось бы так же сделать, но для принятия чего-либо нужно всем голосовать (Андрей и Денис в особенности).

> Некорректно выразился. Не диффы в прямом смысле, а примерно то, что получаем с ноды сейчас. То есть простое построение разностного списка сообщений, но только с учётом того, что было полученно изначально.

Теперь я запутался =) Объясни поточнее, пожалуйста, если не затруднит.

> ps. что-то та станция постоянно отваливается - сейчас написал ответ, а отправить не смог, "сервер не отвечает"

Можешь сидеть на резерве http://alicorn.tk/ii , либо у Андрея. Сам замечаю за своей станцией даунтайм.

> в ii есть запрос /u/e/, который получает список из эх и выдаёт их. в текущем же bosfor, насколько я помню, это не реализовано, и выдаётся просто список сообщений. связано это с тем, что в ii был "список эхи", и "указание на эху в сообщении", в текущей же реализации никакого "списка эхи нет", есть только список сообщений, у которых есть параметр "эха", и по ней всё определяется

Поскольку ii исходит из принципа быстродействия и суперпростоты, делать у нас что-то подобное смысла не вижу. Оно будет сильно загружать процессор и ЖД. Даже если это будет не так, то придётся завязываться строго на базе данных (да пусть если sqlite), то это противоречит идее простоты и универсальности.
ii должен ориентироваться на возможность построения по текстовой БД с малыми потерями в производительности.

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

Требуется сделать возможность наличия двоеточия в имени эхи (и идентификацию эхи по нему) и совместимые msgid? В своих клиентах я это обеспечить могу, мне не принципиально.

14.5 секунд - это генерация :) это время уйдёт на загрузку списка :)

ii12 сделана на текстовых файлах

а сервер при этом упрощается, потому что больше нагрузки идёт на клиенты

> Оно будет сильно загружать процессор и ЖД.

жаль, pentium 150 умер. я бы запустил на нём ноду :)

текущая реализация как раз неоптимальна, и точно загружает процессор и ЖД. первая версия ii (которая была сразу после ii на json) была сильно оптимальная, но не была совместима с фетчерами :)

ii пусть остаётся. но лучше и её перевести на формат ii12, чтобы оно было совместимо полностью

>> 14.5 секунд - это генерация :) это время уйдёт на загрузку списка :)
> Но это же ооочень долго =) и просто недопустимо. 2-3 секунды - максимум для комфортной работы.

там же специально написано, какая стадия сколько занимает :) основное время - это генерация 400000 записей. у тебя они будут получаться по сети, за сравнимое время :)

а для синка "все со всеми" - и 15 секунд нормальное время. он будет отрабатывать раз в сутки, если будет необходимость. если нет - раз в неделю. всё остальное время - оперирование более короткими списками

> 14.5 секунд - это генерация :) это время уйдёт на загрузку списка :)

Но это же ооочень долго =) и просто недопустимо. 2-3 секунды - максимум для комфортной работы.

> ii пусть остаётся. но лучше и её перевести на формат ii12, чтобы оно было совместимо полностью

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