Есть цель заменить ii на другой проект - похожий, но другой. Кодовое имя - bosfor.

ii был задуман... ну, во-первых, ii был задуман, как временный проект, и как подпроект несуществующего ныне odii. а во-вторых, план, который хотелось проверить, был таков - максимально простая реализация на любом языке (включая bash и даже симлинки /m и /e - в принципе, создание симлинков msg на m и echo на e делает полноценную станцию :), да и вообще - всё делается просто). Это направление, как и многое другое, за год было изучено, заэксплуатировано, и признано бессмысленным. Гораздо лучше превратить это в полноценную станцию общения, с сильным сервером и уже какими угодно клиентами. Для клиентов вообще поменяется не так много, а у сервера - изменена логика (но при этом сервер тоже будет делаться просто, но с учётом текущих возможностей).

Использование ORM позвояет делать гибкие запросы, увеличивая возможности. То, чего в ii не хватало - появилось. Поддерживать оригинальный ii я не вижу никакого смысла, проще мигрировать на новый формат, чем держать два формата, делающих одно и то же. Фетчер из ii в bb (с заменой названий эх, если требуется) входит в комплект.

При этом цель простоты никуда не девается. В текущем api еще есть большое поле для упрощения, сделав единый api, которым пользуются и приложения внутри (импортируя модуль bbdata), и внешние клиенты через get/post запросы. Так же в текущем варианте есть проблемы, требующие решения и детальной проработки. Но в целом - это тот же самый старый добрый ii, только со всеми возможностями запросов к базам данных. Его api - это этакий узскоспециализированный couchdb, который будет расти и развиваться.

Основные отличия от ii.

* Адресация - 8 знаков A-Za-z0-9, вместо 20

* Имя эхи - вместо 60 маленьких букв, цифр и некоторых символов, с обязательным цифровым постфиксом - 120 символов без постфикса

* Первое поле отдаваемого сообщения вместо ii/ok или ii/ok/repto/123 содержит bb## или bb##123

* В отправляемом клиентском сообщении - четвёртая строка даёт repto, вместо анализа текста сообщения на предмет @repto (эта недорабтка была мною сразу замечена, но было уже поздно :), поэтому ii проходил с таким костылём)

* Вместо /m, /e, /u, /list.txt и прочего - эволюционирующий api через /bb/

* Поле адрес пока висит под вопросом

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

примеры запросов (после /bb/):

echolist/public/cnt/1
echolist/discover
echo/hc.51:hc25/fmt/bundle
echo/hc.51/fmt/msgid
msgs/12345678,12345679,af52fa25/fmt/bundle/rev/1/page/1/lim/10

всё пока очень сыро

да, важное отличие - эхи теперь получаются только из атрибутов. при этом, в отличие от ii, невозможно, что msgid висит в файле одной эхи, а внутри прописана другая (такое бывало в ii), теперь никаких файлов эх просто нет :). поэтому запрос echo/hc.51:hc25/fmt/msgid - формально не равен /u/e, потому что не прописываются эхи - чтобы использовать таким способом, надо опрашивать каждую эху отдельно, а потом уже получать бандлы с сообщениями. возможно, потом для этого будет что-то сделано, но сейчас главное - очистить и оптимизировать текущий api.


первый тестовый билд:
http://hc25.ru/s/b3firstbuild.tar.gz

пока нет пользователей, всё идёт от одного имени. но для изучения, анализа и внесения поправок - думаю, такого билда достаточно.

Ооо, пришло время почитать исходники =)