Закоммитил в php ноду. https://github.com/vit1-irk/ii-php
Изменения:
1. Вынос фетчинга из конфига. Фетчинг теперь работает по аналогии с ii-rss, что позволяет легко гейтовать сразу несколько нод
2. Незначительные правки

Эта нода уже обновлена. В связи с изменениями в фетчере он теперь запускается через скрипты spline-fetch.php и vargos-fetch.php.

> как они могут отнестись - можно почитать у askz :)
Понял, но попытаться всё равно попробую, когда, хотя бы, релиз будет.
Буду вот сейчас фетчер фиксить, думаю, это в нём проблема.
Можешь, пожалуйста, на всякий случай, скинуть мне код пушера, чтобы легче тестировать было?

Тогда вообще зачем делать гейт в фидо, если оно так сильно огорожено? Их же даже почитать без пароля нельзя. Что там интересного есть?

Конечно, дёргает. Как же я сообщения со station13 получаю? Переименовать на spline-fetch.php и vargos-fetch.php

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

> кроме меня, в кроне, в смысле.
Ну это я не знаю

Приветствую

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

Нет :)
Советую вам, кстати. почитать http://ii.51t.ru, разобраться в терминах

Просто хотелось бы получить эти исходники, потому что отладка скрипта так проще.

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

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

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

> исходники чего?
Исходники пушера, который забирает сообщения с этой ноды и отправляет их на мой php скрипт.

Понятно, спасибо. Исправлю ошибки и заодно портирую пушер.

Вот такая регистрация - супер! То, что надо! :) Только вот на странице "конец игры" самой регистрации пока нет.

Всё правильно.

> гиперболизируя недостатки интернета (но с юмором).
Большой Брат следит за тобой в соцсетях и сливает третьим лицам всю информацию о тебе! Люди общаются на непонятном, укороченном языке.
> "Дурака лелеют, дурака заботливо взращивают, дурака удобряют, и не видно этому конца... Дурак стал нормой, ещё немного – и дурак станет идеалом, и доктора философии заведут вокруг него восторженные хороводы..."

> Надо бы ещё чё-нибудь про офлайновость тиснуть в третьей главе - этого сейчас тоже нет.
По сюжету можно написать, что произошёл сбой, и отключили интернет, а делать из-за этого людям уже нечего, даже почитать предыдущие написанные сообщения нельзя. А ii, как мы уже знаем, имеет иммунитет к оффлайну.

> эха about тоже сливает :) только не совсем понятно, как указанное в наш сюжет привязать? как это выглядеть должно...
Да, но ты сам решаешь, писать в эху что-то о себе или нет, а в современных соцсетях прямо при регистрации (но бывает и позже) тебя чуть ли не принуждают написать о себе всё, что только можно (включая адрес и номер телефона). Конечно, можно не писать, но соцсети просто жаждут от тебя этой информации. Так же можно туда занести контроль за тем, что ты смотришь, впаривание навязчивой рекламы и платежей за неизвестно что.
> Мощная фразочка. Я таких книжек не читаю, поэтому не знал.. надо будет её обязятельно ввернуть кууда-нибудь. :)
Я тоже. :) Просто нашёл хорошую цитату (с лурка вроде), которая под смысл подходит.
> Наверное, третью главу сделать с этим сбоем, когда те, кто замучился от этого, просто перерубили интернет. И юзер ходит по офлайну. :)
Можно написать про ту ситуацию, что правительство сейчас закрывает неугодные ему сайты, а хороших становится всё меньше и меньше (и их тролли атакуют), пока интернет не отключают полностью. Но это уже фантастика :)

Эта регистрация ещё лучше, но вот может убрать этот "no way", где он есть, и написать что-нибудь.

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

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

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

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

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

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

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

Да, паранойя, но она вполне оправдана :)

> Это какбы файлы. По крайней мере, /list.txt
Да, это файлы, которые отвечают за расширение функционала ноды. Но это внутренние файлы, поэтому отдавать их по http абсолютно нет никакой необходимости.

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

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

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

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

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

> + пока тоже на обсуждении. У Виктора есть возражения.
+ принципиально ничего не меняет, по сравнению с тем же слешем, кроме следования формату RFC. Но совместимость сразу пропадёт, поэтому толку особого и нет.

> Ну и P.P.P.S.: Всё равно я бесполезен пока пишу свой клиент. А ведь я ещё и эхокоординатор, оказывается =)
Эхокоординатору положено следить за контентом, поэтому можно просто пару новых эх добавить и что-нибудь туда написать интересного =)

> Итого, 3 за и 1 против.
Ок, соглашаюсь, всё равно проголосовали уже :) Но менять разделитель лучше в последнюю очередь, чтобы совместимость не страдала.

> Насколько я понял, "+" в качестве разделителя будет в /x. Так что никто ничего ломать не собирается.
Ну если в /x, то тогда всё нормально.

Поприветствую всех в очередной раз.
Больше мне здесь делать нечего...

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

Смотрите, первая альфа версия, так сказать: http://irk38.tk/ii/ii-reader.php

Можно протестировать, пожалуйста! У меня у самого CyanogenMod 11 на 4.4.3, qpython неудобно запускать, поэтому родной клиент удобнее будет.

> nightly-debug-билд
По-моему, очень хорошо.

Написал по просьбе Ромы читалку на Tkinter.
http://irk38.tk/files/other/ii-reader-tk.py
Установка - поместить в папку клиента рядом с echo/ и msg/, указать в скрипте нужные эхи в getEchoList

Пока это будет прообразом будущего Desktop клиента :)

Клиент великолепный (с него пишу), но откуда появилась идея брать список эх из echo/?
Я ведь сделал это просто для удобства, это не входит в стандарты, а подписываются на эхи обычно вручную.

> Когда я делал клиент, я не знал какие эхи есть на ноде, чтобы подписаться нужны имена, я не знал откуда их брать. поэтому появилась идея выводить пользователю список эх из бона, /echo и еще там как-то можно, забыл как)
Просто /echo не входит ни в какой стандарт. Когда я хотел скрыть полный список эх у себя на ноде, то добавил заглушку. А потом просто туда написал бонные эхи. Если хочется автоматически подцеплять с сервера бонные эхи, то лучше это делать из bone.14, потому что она, по крайней мере, гейтуется всеми узлами.

> С точки зрения юзабилити было бы неплохо, если бы нода умела сообщать клиенту список общедоступных эх с их описанием.
А с точки зрения простоты реализации это неразумно. Эх может быть неограниченное количество. Не бывает несуществующих эх, бывают те, в которых 0 сообщений. Если хочется автоматически брать список эх, то есть bone.14, ну и bone.15, когда наступит следующий год.

Не работает способ. Копирование/вставка на экране блокировки убраны. Камеру оттуда тоже давно убрал :)

В общем, я решил, что нам это нужно. В качестве api лучше взять /x/echolist (u/трогать не надо). Эхи надо будет добавлять туда вручную: не обязательно бонные, а любые, которые вообще есть.

> У меня нет аккаунта разработчика в гуглплее,
Гугл плей проприетарный и от гугла. Используйте свободные магазины приложений типо F-Droid. И да, лучше выложить исходники.

> Не вижу в проприетарности гуглплея ничего плохого)
Видимо, меня одного тут Столлман покусал? =)

Всё правильно про проприетарщину сказал

> впрочем, о чём я говорю, уже есть стон "моя любимая программа без XP не работает, в XP её никто не переписал, потому что автора нет, а другие не могут"... вот тогда многие подумают, зачем они ели зерно, предназначенное на посадку.... но будет уже поздно. :)
У меня на сканер дрова только на ХР, дрова проприетарные, разработчик куда-то делись, код никто не поддерживает. Ни на новых версиях той же винды, ни на линуксах сканер не работает, а всё потому что драйвер-то проприетарный. Приходится держать виртуалку специально для этих нужд, что зачастую очень неудобно.

> это 15 кб без gzip, или 11 кб в gzip. это проблема?
Если куча подписок, то это, к примеру, 300 кб без gzip и 200 с gzip. На телефоне это очень большая проблема, тем более, по gprs. Даже если в эху никто не написал, всё равно приходится скачивать такие объёмы. Таймстампы очень сильно экономят трафик.

Эху создал, в list.txt записал, всё равно через браузер не заходит.

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

В папке echo создал пустой файл testnode.2014, в list.txt записал её название, толку ноль, но в файле эхи появилось 2 байта пустого текста после попытки на неё зайти. Сейчас дебаг включу.

Попытка доступа была к главной странице

Как сюда файлы посылать? Или можно просто текст копипастить?

ок, перемещаюсь в другую эху

Ничуть не убьёт. У меня официальный клиент на телефоне ничего плохого с карточкой не сделал. Как предложили ранее, можно и sqlite взять - разницы нет