> Кстати, у тебя же есть какая-то китайская коробочка с андроидом, которую ты куда-то там подключал. Можешь завтра на неё клиент поставить и там проверить?

AL> Попробую завтра.

И как оно? Работает или нет?

AL> Я думал сделать дополнительную схему, где по authstr отдавать только те сообщения, которые совпадают с пользователем.

Ради одной-двух эх вводить такое вряд ли имеет смысл, но попробовать можно.

В веб-интерфейсе с шифрованием как таковым дело туго обстоит. Если человек на своём десктопе, то ему ничего страшного, у него есть PGP-софт. Но когда с чужого компьютера сидишь, то уже никак. Сохранять ключи на сервере не вариант, потому что безопасность страдает.

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

AL> Или привлекать PGP и монстрячить способ распросстранения открытых ключей или доверять всем сисопам сети личную переписку, отдавая поинтам только их сообщения. Если честно, мне оба варианта не нравятся. Может, у кого есть идеи получше?

Придётся раньше времени выдавать наши секреты =)
Борис придумал сделать в андроид-клиенте интеграцию с PGP, которую лично я себе представляю примерно так:

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

Выбор ключа и всю грязную возню с криптографией под капотом будет осуществлять свободное приложение OpenKeyChain. Оно, кстати, есть в F-Droid'е, так что за удобный GUI и юзабилити беспокоиться не надо.

---------------

Насчёт фэхи сначала посмотрим то, что ты наваяешь, а потом решим. Но в целом мне эта идея нравится. Даёшь децентрализованный варез и прон!

Ура, товарищи! Можно порадовать вас реальным готовым релизом.
Ссылка на APK висит на главной https://ii-net.tk

Из новых фич, как вы уже догадались, у нас планшетный режим. Со времени предыдущего скриншота я добавил выделение цветом текущего прочитанного сообщения и увеличил размер боковой панели для девайсов с 1000dp ширины и более. И ещё исправил огромное количество багов.

О пользователях с обычными, мелкими экранами тоже забочусь
Что нового:

1. Лента сообщений теперь более юзабельная: последнее прочитанное (в обычных эхах) выделяется цветом
2. В этой же ленте, то есть в списке, включена автопрокрутка до последнего прочитанного, чтобы не потерять нить дискуссии и быстро отыскивать нужное
3. Во внутреннем редакторе убран автофокус на полях ввода, чтобы лучше работалось пальцами (раньше сразу выскакивала наэкранная клавиатура и вызывала путаницу)
4. В непрочитанных сообщениях и в результатах поиска теперь можно выходить в список сообщений для навигации, как и в нормальных эхах.

Тестировать всем обязательно, как можно быстрее! На этот релиз было затрачено всё моё свободное время за эти дни.
По статистике Гитхаба изменено 25 файлов, 1104 additions, 586 deletions. Объём работы большой, и хочется получить отклик.

AL> Мне эта идея в контексте личной переписки всё равно кажется несколько неудобной, так как требует помимо адреса ещё и открытый ключ, а не везде так удобно это делать. Хотя можно через файлэху публиковать %)

Да можно хоть прямо здесь сбросить. Но по канонам криптографии открытыми ключами обмениваются вообще при личной встрече или по нескольким каналам одновременно.

Как-то раз хотел шифрованно послать одному товарищу кое-какой текст. Он опубликовал свой открытый ключ в 3 местах: на своём Гитхабе, через Telegram и в публичной группе ВК.
И только после того, как я убедился, что эти послания все одинаковые (принадлежат одному человеку), мы наладили такой вот дополнительный "канал связи".
Паранойя, конечно, но если ты заботишься о настоящем и хорошем шифровании, то только так.

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

В контексте нашей сети народу будет совсем несложно прокинуть лишнюю эху специально для "лички". Более того, я даже не думаю, что там трафик достигнет больше 30 сообщений в неделю. Плюс PGP заключается в том, что он работает где угодно и когда угодно, он совместим со всем подряд. А открытые ключи заполучать всегда не очень просто.

И эту "личкоэху" можно прописать по умолчанию во всех наших клиентах. А все сообщения "лично для тебя" сразу будут лезть в карбонку (как всегда и бывает), так что не надо будет беспокоиться о работе "из коробки".

Любители экзотики по своему желанию могут личные эхи себе настроить.

AL> По поводу f/e у меня есть мысль в виде спецсимола в перед именем фэхи. Например, как я сделал расцветку квотированных строк в цезии, chr(15) + fecho. Если такой вариант кажется приемлемым, то так и сделаю.

Ни в коем случае! Надо только печатаемые символы. Тем более, если мы будем на фэху в сообщении ссылаться.

AL> Есть мысли что можно добавить и улучшить?

1. Обязательно требуется поле размера файла (в байтах), как сейчас есть в /x/file. Без этого никак 100℅

2. Для обычных эх доступны запросы вида /u/e/echo.1/echo.2, а также расширенный /u/e и /x/c. Для фэх предлагаю сделать то же самое, чтобы они не были неполноценными. Будет что-то вроде файлового IDEC'a

3. Я ещё не уверен в этом, но следовало бы подставлять имя поинта+адрес в метаданные, дабы отслеживать, откуда и от кого ползут файлы.

4. На описание и на имя файла следует наложить лимиты, чтобы не было неожиданностей. На размер пока не знаю, здесь от сисопов всё зависит (ресурсы сервера)

Пока вроде всё

> 2. Для обычных эх доступны запросы вида /u/e/echo.1/echo.2

AL> В случае файлэх нужен механизм однозначного признака, отличающего имя фэхи от имени файла. Поэтому пока нет такого. Но мы ж тут обсуждаем будущее расширение стандарта =) Готов подумать и принять предложения к рассмотрению.

Рома в таких случаях использовал двоеточие. А насчёт имени файла мы поставим его в "запретные" символы. Один фиг в некоторых ФС этот символ нельзя использовать. И слэши точно нельзя, можно их взять

> 1. Обязательно требуется поле размера файла (в байтах), как сейчас есть в /x/file. Без этого никак 100%

AL> В случае файлэхи не очень понятен юзкейс для которого это поле нужно. Можно поподробнее?

Не, ну ты чё. Скачивать файл 2 килобайта и 20 гигабайт есть разница и огромная. Во втором случае я ещё подумаю, надо это мне или нет (особенно если с телефона сижу, где трафик - это время и часто деньги). Да и на серверах ресурсы не резиновые. Это позволит писать скрипты, которые будут рассчитывать свободное место и выдавать уведомления мне как сисопу, например, что, дескать, всё, хватит.

Котов в мешке никому качать не хочется. Особенно если в мешке не кот, а большая связка кирпичей.

AL> Запостить файл с именем, длина которого свалит фс, вряд ли возможно, а описание вряд ли вообще может на что-то повлиять.

Вот так и возникают уязвимости :) Ай да, и так сойдёт, как говорится ;)

Предлагаю имя файла ограничить 256 символами, описание - 4096. В имени файла только английский алфавит, никаких спецсимволов и пробелов. В описании - любой юникод, за исключением двоеточия и переворачивающих последовательностей (для правостороннего набора). Имя поинта и адрес задаются станцией.

vit01>> В имени файла только английский алфавит, никаких спецсимволов и пробелов.

btimofeev> Хотя бы цифры, нижнее подчеркивание (или дефис, для разделения слов) и точку (для расширения файла) надо бы оставить.

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

btimofeev> Так я и не понял: один и тот же файл будет храниться на всех серверах?

Да, а иначе смысла особого в фэхах вообще нет. Есть ведь /x/file
Идея-то неплохая, правда, злоупотреблять ей будут наверняка.

btimofeev> Да и на клиенте мне так же не хотелось бы автоматом выкачивать все файлы.

Мне тоже. Поэтому автоматом только индексы подцеплять буду.

AL> Подписался на фэху и все файлы, попадающие туда, к тебе ссыпятся автоматом. То есть они гейтуются и это в них самое вкусное. В отличии от фреков, мне видится большим преимуществом, что файлы сами будут приходить к пользователям.
AL> ЗЫЖ Вот большие объёмы не знаю как ограничить. Административно или технически.

А вот это очень плохо. Когда у меня появятся фэхи, то поставлю квоту на фетчер не более 100 мб в день.
На клиентах вообще сделаю скачивание исключительно по запросу (обновляться автоматически будут только индексы, а файлы пользователь будет качать сам).

AL> Не взирая на мой предыдущий абзац, пожалуй всё же введу такое ограничение. Причём имя файла я бы подрезал до 64-х ну или хотя бы 128-и символов. Описание тоже срезал бы до килобайта. И то оверхед.

Согласен на 64 + 1024.

AL> и ни в чём не ограничиваем описание. Запрещать всякие спецсимволы это надо подумать. Если не затруднит, можно привести их список, а то я пока не знаю как их искать? =)

Окей, пусть так будет. Не, насчёт спецсимволов я, например, могу припомнить непечатаемые последовательности, которые в консоли есть. Ещё есть переворачиваемая последовательность, которая файл 3mp.exe превращает зрительно в exe.mp3
В идеале надо просто непечатаемые символы удалить, а видимые - оставить. Но не знаю, как это технически реализуется.

AL> А ещё как быть с названиями фэх? Сейчас у меня позволяются вообще любые и я не вижу смысла в обязательной точке, например.

Если мы не будем убирать обязательную точку, то просто сможем заюзать старые фильтры, и не надо будет регулярки переписывать =)
А так пусть ограничения те же будут, что и по стандарту.

AL> Если честно, то мне видятся вполне достаточными ограничения, которые у нас на имена эх распространяются, и в этом случае.

Ладно, сойдёт, так даже проще.
Кстати, репозиторий на Гитхабе с документацией всё ещё доступен тебе для RW-доступа.

vit01>> 4. В непрочитанных сообщениях и в результатах поиска теперь можно выходить в список сообщений для навигации, как и в нормальных эхах.

btimofeev> Небольшой баг: если отключить опцию "Открывать последнее прочитанное", то в вышеназванных разделах вместо списка открывается сообщение. А после нажатия кнопки "назад" открывается список.

Это не баг, это фича. Я специально захардкодил так, чтобы в результатах поиска и в непрочитанных всегда открывалось само сообщение независимо от настроек. Это сделано в целях экономии времени.

И насчёт кнопки "назад" при отключенной (и включенной) настройке поведение мною специально тестировалось. Так и должно быть

vit01>> Из новых фич, как вы уже догадались, у нас планшетный режим.
btimofeev> К сожалению потестить не смогу, т.к. нет планшета, но хотелось бы.

Можешь попробовать поменять 640dp в названиях каталогов ресурсов на меньшее значение.
А ещё в 7 андроиде (да и в 6 тоже) можно менять масштаб изображения на экране в системных настройках. Так что с пятидюймовкой протестировать можешь без проблем. У меня почти на самом минимуме стоит масштаб.

// только что важный коммит сделал, который падение исправляет кое-где, обновись

Вот это на телефоне скрин (5.3'): https://ii-net.tk/screens/Screenshot_20170615-220642.png
Это планшет (7'): https://ii-net.tk/screens/Screenshot_2017-06-15-22-07-07.png

Ты стандарт всё равно опиши в документации, да поподробнее, другим ведь тоже у себя реализовывать надо.

Плюс можно будет определённые куски текста на доработку отправлять, если спор возникнет.

AL> Я начинаю хотеть планшет %)

На самом деле не стоит. Во-первых, в карман фиг засунешь. Во-вторых, придётся таскать клавиатуру, потому что без неё толку от девайса мало (самому вот не повезло, прошивка планшета USB OTG не поддерживает).

Телефон во многом лучше или фаблет. Например, 5.5 дюймов или 6. Там и экран относительно большой, и влезать будет в штаны.

Планшет мне нужен, чтобы тестировать наш клиент на Android 4.4, потому что на основном девайсе семёрка. Ну и для подстраховки таскаю его на дачу (на тот случай, если мобила разрядилась). А так его мать юзает, чтобы кинцо всякое разное смотреть.

Корректирующая сборка

1. Исправлена регрессия с неработающей навигацией по repto
2. Учтены пожелания Бориса по "логичности" открытия списка сообщений
3. Поправлен текст предупреждения о доступе к памяти (чтобы не путать народ насчёт SD-карты)

А может тупо в начало названия файла дописывать имя фэхи при загрузке?

То есть какое-нибудь my.fecho_file1.jpg и my.fecho_text.txt?

atsym> Кстати, а возможно ли сдедать так, чтобы клиент на Android'е работал и без доступа к SD (нет карточки)?

Ему нужна только внутренняя память, то есть /storage/sdcard0

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

AL> Предлагаю упростить всё и оставить только схемы f/e для индексов и f/p для посылки файлов, а для загрузки уже использовать существующую схему x/file.

Отличная идея, полностью за. Только в какой список будем файлы (для /x/file) складывать: в приватный или публичный?

Demon>> Вы знаете как выложить игру в INSTEAD?

AL> Нет.

Сказал держатель репозитория или что ты там хостишь :)

Хотя нет, не очень удобно с точки зрения юзабилити.
А вот для хранения в ФС - сгодится

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

Поэтому различать файлы по хэшу - это неплохая идея.

AL> Например x/file/books/filename.

Небольшая оговорочка: так нельзя. Цитирую документацию:
> GET /x/file/pauth/filename

Текущие реализации должны посчитать books как pauth
Но я думаю, что хрен с ней, с совместимостью. Если надо будет, исправим ноды и клиенты. Мне только в ii-php пару файликов подправить, один python-скрипт в ii-db-utils, а ещё CutieFeed и IDEC Mobile.
Надо сам стандарт удобный, чтобы работал и неожиданностей не создавал.

> fileid:filename:username:address:description

И всё-таки я просто настаиваю, чтобы в /f/e выдавался размер файла в байтах. Мы уже говорили по этому поводу. Нельзя никак качать котов в мешке, пусть даже сейчас мы и предполагаем, что файлы мелкие будут. Это сейчас они мелкие, а потом - крупные.

AL> Да я только за. Перепиши стандарт - я подтянусь. Мне не тяжело.

Готово. Теперь параметр pauth в /x/file доступен только через POST.
Документация обновлена как в репозитории, так и на сайте.

vit01>> И всё-таки я просто настаиваю, чтобы в /f/e выдавался размер файла в байтах.
AL> Этот индекс для автоматического фетчинга. Но добавить не долго, если он действительно нужен.

Понимаю, что для автоматического. Но он нужен и так, и эдак.
И на клиенте, и на ноде размер можно приспособить для мониторинга квоты на скачивание и в целом на ограничения. Плюс на клиенте решать, действительно тебе файл нужен или нет.
Например, я не хочу, чтобы файлы размером более 5 мб (для ноды это может быть 50 мб) скачивались автоматически, пусть скрипты моего явного подтверждения запрашивают. И другие фильтры в таком же духе.

AL> x/file/filename, x/file/pauth/filename:path не пересекаются.

// Тогда уж path:filename.

Окей, это уже сойдёт. Совместимость всё равно поломалась немного (не все ФС поддерживают двоеточия в имени файла), но такой формат будет самым приемлемым в долгосрочной перспективе.

AL> Я вот думаю нафиг там имя, если есть адрес? =)

Вот получили файл от какого-нибудь tavern,22, и народ с чужих станций (не таверны) должен будет догадываться, Вася загрузил файл или Петя.

AL>>> x/file/filename, x/file/pauth/filename:path не пересекаются.
vit01>> // Тогда уж path:filename.

AL> Тут нет двоеточия. Это я наподобии бутылковых маршрутов написал. @route("x/file/<pauth><filename:path>"), что означает, что принимается pauth и filename в виде some/thing/there/file.zip, например. С точки зрения ФС любой ОС всё весьма прозрачно.

Да причём здесь ФС? Как распарсить, что есть что? Надо различить и пароль, и обычный файл

Вот тебе 3 различных варианта

GET /x/file/pauth/fecho.1/file1
GET /x/file/fecho.1/file2
GET /x/file/pauth/file3

Как распарсить первый, ещё понимаю. Но как заниматься обработкой второго и третьего (т.е. как их отличить между собой), не в курсе. Самый простой способ - убрать нафиг pauth из GET-параметров. Более того, все мои клиенты и скрипты, насколько помню, используют исключительно POST, поэтому изменение пройдёт безболезненно.
Я б от этой каши (GET-API) избавился, но кроме моих скриптов и клиентов есть твои, например. Так что ты и решай.

AL> Теоретически мне без разницы адрес там или Имярек Имярекович с адресом. Мы будем знать какого сисопа пинать в обоих случаях.

Окей, согласен.

В целом меня устраивает, но есть очепятки, некоторые фактические неточности и немного недосказанности.
Как время будет, поправлю и смержу

Сделал некоторые исправления и смержил в мастер.
Также английская дока теперь доступна на сайте.

P.S. остальным сетянам тоже желательно хоть как-то прокомментировать сабж и внести исправления, если надо

Мы тут обсуждаем содержание вот этой странички

https://ii-net.tk/idec-doc/?p=protocol-en

Это наши внутренние разборки "под капотом", и они к инстеду не имеют никакого отношения.

AL> За двое суток я пронаблюдал нулевую активность на тестовой ноде. В связи с чем закрыл её за ненадобностью.

Когда ты только поднял ту ноду, я посмотрел, почесал репу и подумал, что пока нечего там было тестировать.

Сначала напишу поддержку фэх в PHP-ноде (+ свой отдельный скрипт с квотой), а там уже и участие появится.

// На дачу стал ездить, времени опять меньше

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

Пока я ездил на дачу собирать клубнику и упарывался в ii://develop.16 (увы, никто это даже не прокомментировал), времени на кодинг совсем не было. А сейчас - появилось.

Что нового:

1. Исправлен баг со скроллбарами в режиме чтения. Спасибо Борису за внимательность
2. Попытался поправить баг с пометкой сообщений прочитанными в списке

И ещё, для всех пользователей клиента я подготовил небольшой сюрприз, о котором здесь не написал.
Обновитесь - увидите =)

Обновляться всем обязательно!

AL> Кстати, есть инструкция как его билдить? Всё таки хочу запилить Solarized расцветку.

Есть. Посмотри в ii://tmp.red.eyes
SDK, кстати, можно брать даже самый новый (но build-tools обязаны быть 23 версии для 32-битных систем).

А ещё я только что специально для тебя закинул в репу скрипт progbuild.sh (в корне). Пропиши там путь к своему SDK, запусти с нужным ключом, и он всё соберёт.

И предупреждаю:

APK, которые я распространяю здесь, подписанные, поэтому установить свой поверх него тебе система не даст.
Так что либо запускай в виртуалке (Android-x86, это очень удобный вариант), либо удаляй моё приложение (перед этим не забудь экспортировать базу данных и конфиг в меню "Дополнительно", дабы заново ничего не настраивать).

AL> Шрифт и правда великоват, а колесо я вообще не увидел =(

Заглянув в исходники, я примерно понял свою ошибку, но всё-таки хотелось бы увидеть скриншот.

AL> Пока не удалось поймать. Чуть позже сбекаплю базу и грохну её, чтобы успеть закринить.

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

vit01>> И ещё, для всех пользователей клиента я подготовил небольшой сюрприз, о котором здесь не написал.

btimofeev> Какое-то все гигантское, и шрифт, и прогресс-колесо))

Всё относительно :)
https://ii-net.tk/screens/Screenshot_20170627-004834.png

Ну ничё, исправим

vit01>> SDK, кстати, можно брать даже самый новый (но build-tools обязаны быть 23 версии для 32-битных систем).

btimofeev> Не обязательно, я себе с 25 версией собираю, нужно просто в файле app/build.gradle номер версии поменять.

Так понятно, что поменять можно. Специально указал, что для 32-битных систем. Или Гугл одумался и выпустил 25 build-tools на старое железо?

AL> А вот колёсико я так и не увидел =(

А ведь я его уменьшил более, чем в 2 раза.
Если ты в режиме энергосбережения или отключил анимации в настройках разработчика, то у тебя должно быть что-то вроде этого:

https://ii-net.tk/screens/Screenshot_20170627-143328.png

Ничё, попробую скоро завести эмулятор 5 андроида, а там и посмотрим.

vit01> Я только что выкатил обновление

Кроме этого в обновлении:

1. Багфикс создания лишних черновиков при повороте экрана
2. Поддержка русских букв в урлах (см. ii://STkMhQ2eSHnTPQqAynts)

vit01>> 2. Поддержка русских букв в урлах (см. ii://STkMhQ2eSHnTPQqAynts)
btimofeev> У меня по этой ссылке открывается список сообщений в develop, а не само сообщение. Но я ещё не обновлялся.

Да, действительно. Надо будет поправить.
// если что, это самое первое сообщение про ту хрень на ардуине, там ещё ссылка на википедию есть

Мини-обновление в клиенте:

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

btimofeev> А что если добавить возможность указывать нескольких пользователей, к примеру, через запятую. На случай, если хочешь, что бы на твоё сообщение обратили внимание определенные пользователи (и что бы сообщение попало в карбонку к ним всем).

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

Хочу заметить, что если мы на filename ставим ту же регулярку, что и на эхи, то максимум будет 120 символов

И насчёт /f/f
Всё-таки решил добавить её вместо /x/file? Почему?

Посмотрел, вроде, всё устраивает. Закинул на сайт. Потом надо будет ещё английскую подправить доку.

// Стыдоба, Андрей. Существительное длина пишется с одной "н". С двумя - только в форме краткого прилагательного :)

Окей. Тогда ставь 120 символов (как для эхи) и прописывай в стандарт.

Только что добавил в клиент очень вкусную фичу - обновление отдельных сообщений с сервера

Например, сослался кто-нибудь на определённое сообщение из индекса, которого у вас в базе нет
Пусть это будет ii://vEdu4F7rwud6zDIpLAZ1

Тыкаете в клиенте на ссылку и видите там [ничего]. Теперь можно зайти в меню и нажать кнопочку "Обновить с сервера". Хоп - и уже готово для прочтения.

Также фича может быть полезна, если у вас есть нода с админкой, чтобы заменять уже существующие сообщения в базе.

На сегодня в обновлении ничего особо серьёзного, однако:

1. Повысилась информативность вывода фетчера (цифры при загрузке корректные + в целом получше)
2. Окно помощи полностью переделано, добавлен раздел для новичков (кстати, он будет выскакивать при первом запуске)
3. В репозитории теперь есть почти пустое README.md

Народу, который сейчас решит обновиться, я дам "на подумать" ссылку вот сюда:
https://github.com/vit1-irk/idec-mobile/blob/master/app/src/main/res/values/strings.xml

Особенно пункты help_about и help_newbie. Причём первый говорит сам за себя :) И за мою лень тоже говорит.

Попробовал установить ради интереса. В целом работает нода, норм всё, но есть несколько "но":

1. Сразу после скачивания из Git запускаю iing.py, жалуется на отсутствие конфига. Хорошо, копирую стандартный. Но, думаю, для развёртки на продакшене людям было бы приятнее и удобнее, если скрипт всё скопирует, даст парочку советов и интерактива.

Например, что-то вроде этого (только по-английски, наверное):

Запускаем ноду в первый раз, копируем конфиги...
Поправьте iing.cfg для настройки станции, образец в README

Создание первого пользователя

Имя: [user1] <Enter>
Пароль: [xxxxxx] <Enter>
Ещё раз: [xxxxxx] <Enter>

Authstr: yyyyyyyyyy, в дальнейшем запускайте points.py, чтобы создать нового юзверя

Listening on 0.0.0.0:3000.... ну и так далее

2. points.py также жалуется при первом запуске на отсутствующий points.txt. Это тоже минус для юзабилити. Написать пару строчек с проверкой и touch() лично тебе несложно, а юзверю хлопот меньше.

3. И уже настоящий косяк, на который нельзя закрывать глаза: iing позволяет создавать пустые сообщения через веб-интерфейс (т.е. пустые сабж и/или тело). По стандарту (да и просто ради отзывчивости интерфейса) оба поля обязаны заполняться. Тогда хотя бы проверку на JS набросай, если лень в основном коде копаться.

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

Например, взять ту же ii-php. Вроде бы, под капотом и в плане API есть неплохие наработки (особенно по транспорту), однако вебморда настолько негибкая, что новые фичи туда фиг добавишь. Увы, практически монолит. Придётся как-то перерабатывать фронтенд с точки зрения архитектуры.

Или CutieFeed. Лично для себя считаю его очень хорошим и юзабельным в момент "здесь и сейчас", но к новым изменениям и в GUI, и по транспорту он почти не готов. Либо втискивать новые фичи в устоявшийся костыль, либо пытаться найти новую парадигму для написания под Qt.

Чё-то делать надо...

C python-софтом (включая Цезий и iing) ситуация в целом как зоопарк. Несколько людей пытаются одновременно реализовывать одни и те же вещи, тратя на них больше времени и усилий, чем нужно.

Предлагаю написать единую библиотеку idec-python, которая будет одинаковая для всех серверов и клиентов, позволяя абстрагироваться разработчикам от самых базовых вещей вроде парсинга сообщений, БД-транспортов, хэширования, эхофильтров, стандартов. Это позволит нам сосредоточиться на GUI, сэкономит кучу времени, даст работать гораздо более эффективно.

Плюс будет проще продвигать нововведения и бороться с багами. А ещё есть надежда, что idec-python позволит постепенно стереть грани между клиентом и сервером. Надо сказать, я задумывался и над привнесением в IDEC Mobile такой фичи, чтобы клиент работал в режиме станции.

// Мечтать не вредно...

AL> Исправил все три замечания.

А вот и не все. Чистая нода из репозитория всё так же валится при запуске, жалуясь на отсутствие конфига.

Если я скопирую конфиг вручную и попробую её запустить снова, то она даже не выдаст предупреждения, что points.txt пуст (и что его следовало бы наполнить чем-то).

Кстати, ещё заметил, что если в points.py не до конца указать параметры командной строки (например, только -u user, без пароля), то скрипт не обрабатывает исключение, а вываливает Traceback. Тоже непорядок.

----

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

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

1. Качаем репу, ставим зависимости
2. Запускаем скрипт
3. Пытаемся получить поинта и написать "test"
4. Если всё норм, настраиваем эхи и фетч

Пункты 2 и 3 проще совместить, чтобы всё было "не отходя от кассы". Также можно облегчить пункт 4, дав небольшие подсказки, и/или сразу конфиг подогнать.