А кто такая строка-авторизации? В readme не написано, другой документации нет, из приложенного конфига непонятно, что это за зверь.

А в сорцах без пол-литра не разобраться.

> А в сорцах без пол-литра не разобраться.

Методом тыка.

> А как ты авторизовался без строки авторизации? :)

Так нигде не говорилось, что это и есть строка авторизации. Вдруг там чего хитрое должно быть. В клиенте по дефолту вообще :no: -- понимай как хочешь.

Вот что мне не нравится, так это префиксы. По крайней мере пока они недетерменированы. Потому что это нарушает принцип целостности эхи. Эха скачет по префиксам, сами префиксы не стандартизированы, нужно переподписываться, причем руками.

Постфиксы. Смотря с какой стороны читать.

Как только увидел существующие клиенты для ii, сразу зачесалось написать свой. И вот: https://github.com/6vasia/ncii
Умеет пока немного - ридонли, без локального кэша.
В ближайших планах: локальный кэш, отправка сообщений.

Зависимости: perl5, libwww-perl (LWP::UserAgent сотоварищи), Curses::UI, YAML.
Выглядит так: http://itmag.es/4CoXh

http://stackoverflow.com/questions/2659952/maximum-length-of-http-get-request
Я ограничился пачками по 100, это чуть больше 2kB.

> нахрена? к тому времени, когда это будет применимо, уже будут пост-запросы :)

Попробуй выдернуть im.1406 одним куском, например.

Обновление клиента!
- Локальный кэш
- Немного изменились хоткеи

> Обновление клиента!
Ах да, конфиг теперь можно держать в текущей директории, но кэш всё равно будет в
~/.config/ncii/

Какая ОС?
Ну и попробуй просто cpan -i Curses::UI

>> Обновление клиента!

Сегодня у нас праздник! Клиент обрел возможность отправлять сообщения.
К сожалению, для нормальной работы с utf8 требуется хак/патч Curses::UI, поэтому, или пользуйтесь приложенной версией, или страдайте.

http://itmag.es/3bTXa

Вызов окна по клавише `n' для нового сообщения или `r' для ответа.
Хоткеи в окне:
C-s - положить в очередь для отправки
C-q - закрыть и забыть
TAB - перемещение по полям
ENTER в поле предпросмотра - вызов внешнего редактора.

Редактор задаётся переменной окружения EDITOR или в конфиге опцией editor.

>OS убунта

Тогда поставь libcurses-ui-perl из репозитория и не мучайся.
А лучше только libcurses-perl, пакет я приложил, а в репозитории он с ошибкой.

>> Ну и попробуй просто cpan -i Curses::UI

>Энта команда выдала точно такой же результат http://pastebin.com/YLhY3mVq

А если всё-таки захочешь ставить с CPAN'а, то поставь libncurses5-dev.

Тьфу, забыл. authstr в конфиг пропиши.

>ps. когда ставится Re (2) - официальный клиент и сервер тебя не понимают, они ориентируются только на 'Re: '

>лучше не вешать эти цифры ненужные, а делать, как в голдеде - кнопки "назад по треду" и, возможно, "вперёд по треду"

А они их вообще как-то обрабатывают? Я заметил только в вебморде реакцию на @repto.

>> А они их вообще как-то обрабатывают?

>см. на текущий заголовок, например.

Жуть. Отключил пока, потом придумаю что-ть более изящное.

Очередь неотправленных пока немного глючит, шлём по одному.

>Шеф! Заработало! Почти...

>Как кодироффку починить та?

Как ты ставил и что именно не работает? Как выглядит?

>В общем доустановил библиотеку libcurses-perl и оно запустилось. Выглядит так https://dl.dropboxusercontent.com/u/4534287/1.png

>P.S. просьба сделать в клиенте всплывающую подсказку по хоткеям

Такого я еще не видел. Какая локаль?

>Русская локаль жеж.

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

По идее, libwww-perl, libyaml-perl и libcurses-perl.
Запусти еще iitest.pl на всякий случай, и посмотри, нормально ли кириллица выдается там.

>Все три библиотеки установлены.

>А при запуске iitest.pl вообще показывает странное:

Запускай как perl iitest.pl. И дерни последний, в старом 51t прописана.

>Обновил. iitest.pl проходит. Там все по-русски.

Уже что-то. Попробуй удалить libcurses-ui-perl и взлететь на том, что приложен.

>P.S. кстати, куда вписывать свой хэш в конфиге?

authstr: <hash>

>> Попробуй удалить libcurses-ui-perl и взлететь на том, что приложен.

>libcurses-ui-perl удалил, ничего не изменилось. Или там как-то по особенному надо взлетать?

Сча потыкаю на своей хрубунте. Мне туда надо русские шрифты для начала поставить.

>>> Попробуй удалить libcurses-ui-perl и взлететь на том, что приложен.

>>libcurses-ui-perl удалил, ничего не изменилось. Или там как-то по особенному надо взлетать?

>Сча потыкаю на своей хрубунте. Мне туда надо русские шрифты для начала поставить.

Вот не знаю я, что у тебя не так. Пишу с убунты, на которую только что накатил поддержку русского.

2All: Есть у кого идеи?

>> Попробуй удалить libcurses-ui-perl и взлететь на том, что приложен.

>libcurses-ui-perl удалил, ничего не изменилось. Или там как-то по особенному надо взлетать?

А писать тоже не получается?

>Писать можно только в поле Subj и то, только латиницей, кириллицей сразу пишет кракозябры.

А выложи куда-ть свой кэш. Он в ~/.config/ncii/*.dump

>А в поле письма вообще нет курсора и писать туда нельзя вообще.

Так задумано. Если нажать ENTER, откроется внешний редактор.

>Писать можно только в поле Subj и то, только латиницей, кириллицей сразу пишет кракозябры. А в поле письма вообще нет курсора и писать туда нельзя вообще.

Если новую ветвь начать, то тоже?

>Кэш https://dl.dropboxusercontent.com/u/4534287/irk38.tk.dump

Выглядит нормально. Проблема в Curses, но у меня с ним такого никогда не было :\

>> Если нажать ENTER, откроется внешний редактор
>Нажимаю и открывается надпись "Editor not defined. Use config or EDITOR variable." хотя как я понял должен открываться умолчательный nano?

Да. Проверь переменные окружения, если EDITOR не прописан, можно прописать в конфиге, например:
editor: nano

>Да, я попробую завести на Mono, дома как раз гента стоит:)
>Правда я пишу в 2013 студии, но там перенести проект в 2010 пара пустяков.

>Ну и код не особо академический. Но я стараюсь:)

Не надо академического кода! Ты исходники OpenSSL видел? Уж0с.

>Managed языки более безопасны, там не будет таких дыр в прикладном по:)
>Под академическим кодом я подразумевал, что возможно не все красиво, универсально, интерфейсно и прочее:)

Так я не про дыры. Там сам код читать страшно.

>Кто поделится со мной рецептом запуска сабжевого улиента "с нуля"? Интересно же что конкурент делает =)

Почти по мануалу. Тебе нужны perl5, LWP, Curses, YAML и Term::Readkey. Для дубиана-убунты это соответственно libwww-perl, libcurses-perl, libyaml-perl & libterm-readkey-perl.

Далее конфигаешь почти по примеру, добавляя authstr и editor по вкусу.

>>Разница в том, что php-нода принимает только urlsafe. В im.100 уже рассудили, вроде, сегодня. Глянь, там Виктор что-то объяснял. Я только не очень понял что =)

>Блин, это мне, значит, надо писать два обработчика и непонятно как определять где запущена какая нода. Да ну нафиг такое ваще...

>В ncii это как обрабатывается? Я бы код к себе утянул, если знать где смотреть

Весь код взаимодействия с нодой в II/Point.pm. Но я делал по стандарту, обычный base64, POST.

>>Или просто пыхонода работает не так как питононода?

>Разница в том, что php-нода принимает только urlsafe. В im.100 уже рассудили, вроде, сегодня. Глянь, там Виктор что-то объяснял. Я только не очень понял что =)

Щито? Смотрим код.

> ii-functions.php:

> 40: function pointSend($msg,$authname,$addr) {
> 41: $goodmsg=explode("\n",b64d($msg));
> 42: ...

> 24: function b64d($s) {
> 25: return base64_decode(str_pad(strtr($s, '-_', '+/'), strlen($s) % 4, '=', STR_PAD_RIGHT),true);
> 26: }

Как вам идея ротации эх a la logrotate?
Т.е. Текущая эха имеет имя areaname.0, как только упирается в лимит, все сообщения из нее улетают в areaname.1, архив сдвигается на 1. areaname является алиасом к areaname.0.

>Идея хороша, но алиас не нужен

Алиас короче же.

>> Алиас короче же.
>Короче, но накладывает ограничения. К примеру, у нас есть im.100, когда она переполнится, она станет, к примеру, im.101, но из-за алиаса всё усложняется, не имея особого смысла.

Я предлагаю алиасить только ".0", т.е. "im.100" остается "im.100", а к "thing.0" можно обращаться как "thing.0", так и "thing".

>> Я предлагаю алиасить только ".0", т.е. "im.100" остается "im.100", а к "thing.0" можно обращаться как "thing.0", так и "thing".
>Тогда не проще ли так сделать на стороне клиента?

Не то чтобы проще, но, действительно, логичнее.

Дефолтный текстовый клиент больше не падает при получении пустых сообщений.

Обновился дефолтный сервер на питоне.

Добавлен расширенный интерфейс /x. Текущая реализация содержит только метод /x/mtime, который возвращает время модификации эхи. На входе список, на выходе список вида

echoname1:mtime1
echoname2:mtime2

>Добавлен расширенный интерфейс /x. Текущая реализация содержит только метод /x/mtime, который возвращает время модификации эхи. На входе список, на выходе список вида

Кстати, насчет списков. Мне не нравится / как разделитель. В урле. Вот вообще.

>> Добавлен расширенный интерфейс /x. Текущая реализация содержит только метод /x/mtime, который возвращает время модификации эхи. На входе список, на выходе список вида
>Почему /x? Стандарты надо чётко продумывать. Не лучше ли было сделать /u/t или просто /t? Хотя, наверное, это просто мои придирки.

Потому что eXtended API. Если примем в стандарт, то можно и /u.
Я бы еще уточнил интерфейс, сгруппировать методы по группам, /e/<method> для эх, /m/ для сообщений и т.д.

>> Кстати, насчет списков. Мне не нравится / как разделитель. В урле. Вот вообще.
>А по-моему, удобно. Но base64 urlsafe добавляет свою специфику.

Удобно, но не очень логично, а я не люблю, когда нелогично. Поясню:
/u/e/name/name/name... - где namespace, где метод, где параметры, сколько параметров? Всё в кучу.

>Обновился дефолтный сервер на питоне.

Методы /list.txt и /blacklist.txt не являются частью стандарта, нигде не описаны и вообще.
Теперь они являются устаревшими и будут возвращать 'deprecated'.

Также устаревшими являются методы /e и /m, со временем они будут убраны.

Неймспейс /u пока под вопросом. Если оставлять обратную совместимость с существующими клиентами, то его придется оставить неизменным и делать новый, например /x.

В обновленном API разделителем списков будет '+', немного изменится интерфейс, будет добавлен метод для получения timestamp'а эхи.

Что касается ротации, всё чуть сложнее, чем кажется, но реализуется довольно просто.
Посколькю сеть распределенная, то каждая нода устанавливает свой лимит на количество сообщений и осуществляет ротацию самостоятельно. Или вообще не осуществлет.
Порядок ротации/фетча прописываем в стандарт.
При фетчинге топовой части эхи нода также должна дергать все предыдущие, т.к. новые для нее сообщения могли уже уехать, и слияние осуществляет также со всем своим архивом. Новые сообщения идут в топ.
Иначе будут постоянные дубли.

Такова плата за децентрализованность

>Пришлось проснуться и ответить...

Да ладно, пока и без этого есть, чем заняться.

>> Методы /list.txt и /blacklist.txt не являются частью стандарта, нигде не описаны и вообще.
>> Теперь они являются устаревшими и будут возвращать 'deprecated'.
>Это не методы, это внутренние файлы ноды, их вообще не надо показывать наружу, поэтому убирай (и можно даже без депрекатед).

Это какбы файлы. По крайней мере, /list.txt

>> Также устаревшими являются методы /e и /m, со временем они будут убраны.
>/e убирай, так как оно практически дублирует поведение /u/e, а вот /m убирать не надо, так как оно полезно для отладки.

OK, /m оставим.

>> Неймспейс /u пока под вопросом. Если оставлять обратную совместимость с существующими клиентами, то его придется оставить неизменным и делать новый, например /x.
>Не надо убирать! Если нужно новые функции, то лучше добавить их в /x

>> В обновленном API разделителем списков будет '+', немного изменится интерфейс
>Ну почему плюс? Со слешем же всё нормально было, зачем переусложнять?

С точки зрения кода вообще пофиг, какой разделитель.
Мне не нравится слэш, потому то по задумке и RFC это разделитель для обозначения иерархии объектов в урле. Т.е. то, что слева от слэша стоит по иерархии выше, чем то, что справа. Плюс же -- общепринятый разделитель равноправных объектов в урле.

>> Что касается ротации, всё чуть сложнее, чем кажется, но реализуется довольно просто.
>С ротацией разберёмся позже, сейчас усложнять стандарт не надо.

Когда-нибудь это надо сделать, и чем раньше, тем будет проще, тем меньше пользователей пострадают.

>И да, почему вдруг стандарты так быстро меняются? А спросить, нужно или не нужно? А сообщество наше?

Стандартом является то, что описано в официальной документации, остальное -- предложения.

>>Неймспейс /u пока под вопросом. Если оставлять обратную совместимость с существующими клиентами, то его придется оставить неизменным и делать новый, например /x.
>Я считаю что надо оставлять /u до последнего. Чтобы не пришлось в спешном порядке менять софт на узлах и на станциях поинтов. В конце концов это не столь обременительно.

Мне тоже ближе эволюционный метод, поэтому на /u пока никто не посягает.

>>В обновленном API разделителем списков будет '+', немного изменится интерфейс, будет добавлен метод для получения timestamp'а эхи.
>Вот это хорошо. Теперь можно будет не дёргать зазря списки и не выстраивать пустые diff'ы при каждом обмене. Одобрямс =)

Таймстемпы будут на серверах, когда мы утрясём API и оно будет везде реализовано.
Некоторым не нравится длинное имя метода /x/mtime и есть вариант сделать просто /x/t. Более того, оно в /x, а не в /u, поскольку не входит в изначальный протокол и является по сути необязательным расширением.

+ пока тоже на обсуждении. У Виктора есть возражения.

>>Что касается ротации, всё чуть сложнее, чем кажется, но реализуется довольно просто.
>>Посколькю сеть распределенная, то каждая нода устанавливает свой лимит на количество сообщений и осуществляет ротацию самостоятельно. Или вообще не осуществлет.
>>Порядок ротации/фетча прописываем в стандарт.
>>При фетчинге топовой части эхи нода также должна дергать все предыдущие, т.к. новые для нее сообщения могли уже уехать, и слияние осуществляет также со всем своим архивом. Новые сообщения идут в топ.
>>Иначе будут постоянные дубли.
>Вот этот момент не очень понял. Я так понимаю что ты хочешь добавить возможность получать diff прямо с ноды, а не выстраивать его на стороне фетчера?

Если бы можно было относительно безболезненно выстраивать diff прямо на ноде, это бы была сказка. Но для этого на ноду пришлось бы передавать весь локальный список, что неправильно. Поэтому разницу выстраивает фетчер/поинт.

Речь идет о идее ротации, которую я предложил, она тут многим понравилась, но она довольно революционна для местного сообщества и требует некоторых изменений в механизме обмена и хранения, т.е. в самой сути ii. Это попытка уйти от ручного управления постфиксами без необходимости (поинтам) вытягивать весь архив целиком.

Оффтопик. Я начинаю присматриваться к идее с уровнем пробелами, но пока сомневаюсь. При большом уровне вложенности/ответов от темы ничего кроме пробелов не останется.

>Так как мы присобачиваемся к http, то действительно хорошо бы его стандарты и традиции собдлюдать в форматах. Я за "+", если что. Хотя, логичнее было бы провести голосование.

Я веду статистику :)
Из разработчиков Виктор против, мы с тобой за, Дифрекс не высказался.

>А. Но как бы там ни было, меня больше смущает текущая база. Когда-нибудь мы всё таки упрёмся в возможности ФС и работа с базой сообщений будет ох какой неторопливой. Конечно, никто не мешает завести архивную ноду и перенести старые эхи туда, но это решение ли это? Я уже второй день думаю над этим вопросом и пока что решения смены базы и архивных узлов перебарывают друг друга с загадочной периодичностью.

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

Меня как раз больше всего напрягает геморрой с постфиксами. Текущее решение формой подозрительно напоминает костыль.

>>Я веду статистику :)
>>Из разработчиков Виктор против, мы с тобой за, Дифрекс не высказался.
>Я высказывался, что слэши в качестве разделителя меня не очень прут. :)

Оу. Извини, иногда тут непросто что-то отслеживать.
Итого, 3 за и 1 против.

>>Никто не запрещает хранить сообщения в SQL/NoSQL СУБД.
>>ii это по сути протокол обмена, а как именно ты хранишь данные это не имеет значения.
>Ну обратного я и не утверждал. Но прикручивать СУБД это оверхед.

Можно сериализовать средствами языка (или сторонними). Эхи сериализуются в лоб, сообщения кусками с индексом.

Нет способа отличить esc от esc-последовательности. Esc даже не трогай.