и она мне нравится

пока, конечно, неофициально и экспериментально, а там

1. zlib вне python юзать не так просто. как, например, gzip. вся разница в несколько байт заголовка, а плоская распаковка - сильно лучше

2. url-схемы, которые и определяют, будет ли использоваться gzip или нет, какой будет base64. чтобы простые серверы использовали просто, а сложные - сложно.

3. база. база сообщений, которую так запросто и неперемаркируешь. сейчас я впереди ставлю ii/ok в виде доп.ключа, чтобы можно было распознавать сообщение. вопрос только в том, считать это опцией или обязаловом. если в стандарт - то лучше делать это, как можно раньше

чёто ещё забыл.

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

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. пока будет опциональным. пусть внедряется. :)

А в дальнейшем (пока оставим для совместимости с 0.2 клиентами, но документировать не будем) можно вообще отказаться от z-схемы. Явное "переусложнение".

Я за схему, где можно указывать как /z/, так и get.php?q=/z/ - удобнее писать сервер - а клиентам должно быть всё равно

Ещё надо механизм ограничения выдачи сообщений, по 100-200 (как серверу удобнее) штук за раз, а потом маркер что не все сообщения (ii/part вместо номера сообщения), за следующей порцией приходи ещё раз. Если сообщения отправлены целиком - тогда ii/ok последней строкой.

Авторы, очень прошу для хранения сообщений использовать не ~/.ii, а ~/.share/ii или ~/.local/ii
Не надо забивать домашний каталог.
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html $XDG_DATA_HOME или $XDG_DATA_DIRS

> Я за схему, где можно указывать как /z/, так и get.php?q=/z/ - удобнее писать сервер - а клиентам должно быть всё равно

Так она такой и будет. она и сейчас такая :) просто делать идентичный zlib в других языках - заумнее, будем делать проще. Просто там были разные офлайновые или полуофлайновые варианты, но теперь лучше про них вообще не сильно думать, спокойно их придумывая отдельно. :)

> Ещё надо механизм ограничения выдачи сообщений, по 100-200 (как серверу удобнее) штук за раз, а потом маркер что не все сообщения (ii/part вместо номера сообщения), за следующей порцией приходи ещё раз. Если сообщения отправлены целиком - тогда ii/ok последней строкой.

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

> Авторы, очень прошу для хранения сообщений использовать не ~/.ii, а ~/.share/ii или ~/.local/ii

Чем дальше спрячешь - тем сложнее крутить руками :) я бы вообще не .ii а ii сделал. потому что там в довесок будет ещё десяток утилит поиграться, и бегать с ними в тридесятое царство - это неудобно. Посмотрим, я ещё вообще об этом не думал, это требования дистрибутивов. Куда у них там положено, туда и положим. :)

А раз существует файл list.txt - то добавить файл api.txt
----
echo=/e/
msg=/m/
zecho=/z/e/
zmsg=/z/m/
push=/a/newmsg/<echoarea>
----
Или кому как нравится
----
echo=echo.php
msg=msg.php
zecho=echo.php?z=1
zmsg=msg.php?z=1
push=push.php?a=<echoarea>
----
+ совместимость
+ универсальность

- надо парсить подстановки типа <echoarea>

нам нужен стандарт. чтобы делать простые серверы и простые клиенты. а потом уже, может быть, из простых вырастут сложные. сами по себе - точно никакие не вырастут

нет, добавления ничего пока не будет. я сейчас, наоборот, только сижу и удаляю, что можно :) текущая технология, за исключением /z/, меня вполне устраивает, как серверы, так и клиенты. они и будут эталонной реализацией.

а распарсить строку сможет любой сервер, будь то php?q=/u/ или /u/

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

Для /z/get/ было описание, а как теперь правильно забирать список новых сообщений?

> Чем дальше спрячешь - тем сложнее крутить руками :) я бы вообще не .ii а ii сделал

Это просто удобнее. Некоторый софт уже перешёл на хранение в .local. Как пример mc - при обновлении он предлагает перенести свои настройки из ~/.mc в ~/.config/mc

> Для /z/get/ было описание, а как теперь правильно забирать список новых сообщений?

z/get делал бандлы эхи. это противоречит идеологии. :) сейчас пишу описание запросов, их там всего пока будет 5 штук, два плоских /m/ и /e/ и три, заменяющих аналогичные /z/ - это u/e, u/m и u/point пока на этом всё.

> Это просто удобнее. Некоторый софт уже перешёл на хранение в .local. Как пример mc - при обновлении он предлагает перенести свои настройки из ~/.mc в ~/.config/mc

но ты же не лазишь туда постоянно. а там у тебя конфиги, базы, и прочее, к чему можно утилитами прикоснуться. или у тебя cd ii либо один клац в mc - и ты уже там, или ты бегаешь по дереву и ищешь, где бы это изменить :)

ii://to.doc.14

вот тут постепенно буду кидать тексты, которые планируются в документацию добавиться, подпишись/смотри и читай.

>> to.doc.14

Отлично, добавь её в list.txt, чтобы она в общем списке была.

wiki.51t.ru можно использовать как-то?

> это выглядит, как разработчики svn, которые пользуются git для разработки svn :)

вот, что называется

> Проект Apache Subversion начал перевод своей кодовой базы на использование Git. Разработка системы контроля версий Subversion отныне будет вестись в Git-репозитории. Миграция позволит проекту уйти от централизованной организации разработки к децентрализованной модели. Для Subversion также представлен бэкенд для работы через Git.

а я ведь просто так ляпнул, я даже не знал. :) видимо, идея уж слишком на поверхности :)