Длинные номера неэлегантны и несовместимы с uliss. Сам uliss я пока отложу, и сделаю простое решение, взяв лучшее из обоих (надо бы и англоязычную версию сделать). ii изначально был временным, на нём всё отлаживалось, и сделав кучу всего на нём я вижу и достоинства и недостатки. Хочется добавить идеальности :) Отбросить лишнее, добавить нужное (нормальные repto, например :). Адреса я убрал, хотя это не принципиально.

По аналогии с ulissdata, будет модуль bbdata, который можно будет легко добавлять в нужные приложения, и он будет опрашиваться по тем же самым api. То есть, у сервера будет api, который пользуется всеми преимуществами sql (схемные движки плохи при разработке и развитии, но когда схема полностью устаканилась - это то, что нужно), и уже клиент будет выбирать, какие данные ему нужны, логика получения данных ложится на клиента и его стратегии опроса - а api опроса будет универсальным и фактически единым и для веб-интерфейса с его приложениями, и для запросов клиентов (в любой форме).

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

В общем - такой переходной проект, plaintext-формат от ii, идеи от uliss, никаких объектов и переусложнённостей - только сообщения [фиксированное число полей] и эхи. :)

Сейчас используются схемы msg:// и echo://, а вообще мне хочется для имени эхи использовать :. типа :openbsd... сейчас, видя #blabla, ты понимаешь, что это твиттер, этакая недоэха, которая непонятно, как работает :) Если создавать легенду :), и альтернативу под свои задачи - нужны символы и знаки. :)

Кроме карбонок, наверное, надо делать и свод эх (в табличном виде это просто, хотя у меня на архивных станциях были и на простом ii), и возможность посмотреть все эхи на станции, а не только опубликованные (это лучше, чем текущий "секюрный" вариант "не показал - не знают", но можно предусмотреть и секурность, обрубив эти api). Тогда будет больше возможностей для автосинхронизации. Вообще, в uliss сейчас никакого понятия "файл эх" нет, есть только модель для сообщений, а "эхи" строятся по выборкам. При синхронизации, вероятно, имя эхи тоже будет извлекаться из сообщения (но это опять варианты для клиентов, как им больше нравится).

В общем, вместо разных урлов - единый api, с которого можешь наковырять всё, что хочешь тем способом, который тебе нравится.