>Это просто наблюдение, так то WASD норм, только знать надо об этом. :)

Сейчас для этого я рисую небольшую инфографику для помещения на главной под списком конференций.

> И на hjkl продублируй, для вимеров)

Вимеры сильно обидятся, если я не буду для них рисовать инфографику, а просто напишу, что также можно использовать vikeys?

Нода работает по какому-то графику или как придётся? Просто наблюдаю достаточно стабильный её оффлайн.

Итак. Я доделал адаптивный интерфейс. Теперь совершенно вся вебморда таверны приспособлена для использования на девайсах с мелким экраном.

Следующий шаг - перевод базы в sqlite3.

Эксперимента ради таки добавил в сабж (в апстриме iing этого пока нет) js-скриптов маленько. Теперь на главной можно мотать страницу посредством W и S, а в режиме чтения эхи можно пользоваться WASD для листания сообщения и перелистывания на следующее/предыдущее. А так же использовать Q для возвращения на главную.

Лично мне эта фича безумно нравится и я подумываю пушнуть её в апстрим. Что скажете?

> Сейчас ещё лучше, но баги всё равно есть
> Например, тот, про который я уже сообщал: https://ii-net.tk/screens/Screenshot_20170522-140701.png

Поставлю хром и посмотрю. В лисе не воспроизводится а то.

> И ещё вылезающий за границы экрана текст на главной странице: https://ii-net.tk/screens/Screenshot_20170522-140639.png

А вот это, вроде, поправил. Во всяком случае перестал воспроизводиться и на телефоне и на десктопе.

> Народ, подкиньте какой-нибудь милашный скрин текущей версии Цезия.

http://spline-online.tk/stuff/docs/pics/caesium_20170522.png

Не знаю насколько он милашный, но я так в секточке чижу.

>> Например, тот, про который я уже сообщал: https://ii-net.tk/screens/Screenshot_20170522-140701.png
> Поставлю хром и посмотрю. В лисе не воспроизводится а то.

Так и не смог воспроизвести, но беглое гугление подсказало один из вариантов. Проверь. Вдруг помогло.

>Другое дело, что именно за клавиши использовать. Часто (почему-то) для следующий/предыдущий -- используют пробел и backspace.
>Но пробел в браузере обычно это листание страниц. Может стрелки стандартные?

Я думал над этим. В играх не зря используют WASD, ИМХО. Это очень удобно, если при этом всё таки тягаться за мышкой и при этом быстро использовать всю клаву (в случае таверны быстро перенести вторую руку с мыши и начать печатать).

На всякий случай сообщаю, что робота, собираюшего сабжевую эху я выключил. Причина в том, что я как сисоп несу ответственномть за трафик, идущий с моей станции, и не хочу распространять ни контент 18+ ни рекламу такого контента. Может быть, буду наполнять эху вручную. Или удалю со станции. Договориться с администратором сайта не удалось и добавить в RSS теги для фильтрации он отказался.

> Это у тебя кажется terminus bold, наверное поэтому мне не привычно.

Он самый. Просто у меня от тонкого начертания при больших размерах (на скрине для меня уже шрифт крупны) глаза устают. А вот при bold нет.

>> Не знаю насколько он милашный, но я так в секточке чижу.
> Здесь, конечно, лютое ШГ, но для документации и главной сойдёт, спасибо :)

Куда катимся. Терминус ШГ называть =)

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

Хорошо, что у нас пока анархия работает и в полноценной работе сети заинтересованы все сисопы.

Если что, то срач в r50.sysop начался с невинного вопроса о том, нужно ли заменять в тексте заглавную русскую Н на заглавную латинскую H. Или это уже пережиток прошлого. За чем последовал долгий срач с неправомерным отключением от бонных эх целых узлов.

>> Если что, то срач в r50.sysop начался с невинного вопроса о том, нужно ли заменять в тексте заглавную русскую Н на заглавную латинскую H. Или это уже пережиток прошлого. За чем последовал долгий срач с неправомерным отключением от бонных эх целых узлов.
> Это уже какой-то абсурд. Из-за такой мелочи пересраться... Круто, что у нас пока что более-менее дружбомагичная атмосфера здесь.

На самом деле чисто теоретически это может привести к некоторым проблемам с её отображением, так как Fido появилось в штатах и в 1983-м году. Никак не предполагалось, что 0x8D будет присутствовать в письмах. Когда же Fido пришло в Россию и уже была продавлена кодовая страница 866 в качестве стандарта де-факто, оказалось, что 0x8D это "Н". И совсем древний софт это не учитывал. Но с тех пор прошло более двадцати лет и даже узлы, много лет находяшиеся на автопилоте, спокойно обрабатывают этот символ, то практической проблемы не возникает. Но зато есть отдельно упёртые сисопы, которые ратуют за "традиции"(tm) и ретроградство.

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

Короче, координаторы молчат, сисопы срутся, а замена продолжает иметь место быть =)

> Анархия - это хорошо, когда мало народу. Думаю, на 10 станциях с 2 активными поинтами на каждой всё ещё можно будет прилично сосуществовать.

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

Посмотрел я iing из гита. Фоновой картинки нет потому что она в конфиге не прописана. Там пока криво сделано: надо прописать "background filename", где filename - имя файла фоновой картинки из директории lib/.

По поводу стиля изменения внёс (пока не пушнул правда). Потестируй пожалуйста и отпишись о результатах.

> Вдохновлялся Андроид-клиентом; значки от Гугла, как и полагается. Коммитить пока не буду, времени нет :)
> Хотя идей и здесь полно, каких можно дореализовать.

Как сделаешь сборку под винду свежей версии, отпишись пожалуйста. Есть один знакомый, который заинтересован в саюже под винду.

>> Так что я взял и загрузил в него таверну.
> Ты ведь не через интернет её загрузил, верно?

Через локалку :)

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

Я уже практически спал и формировать бандо мне было лень. Локалка это всяко быстрее, чем вылазить из под одеяла, плестись в другую комнату и включать ноут для подключения к серверу. И гораздо проще, чем использовать ssh на телефоне :)

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

Заметил тут что на моём смартфоне стал подтормаживать hotdoged (это который про фидо). Связано это с довольно разросшейся базой. В связи с чем стало интересно как себя будет чувствовать сабж в таких условиях. Так что я взял и загрузил в него таверну. И был приятно удивлён отзывчивостью программы. Скорость работы существенно выше, хотя я пока не смотрел объёмные сообщения с большой глубиной цитирования, а ведь все мы знаем что обработка текста удовольствие дорогое.

В целом от версий, выпущенных после введения индексов в базу, я доволен как слон.

В очередной раз задумался о расширении стандарта.

Первое (уже озвученное ранее) это нетмейл. То есть личная переписка.

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

// В любом случае, нетмейл будет ходить не между всеми узлами, а только между доверенными, но это всё равно не гарантирует безопасности.

Второе (вот тут не уверен, что вопрос поднимался мной ранее), это файл-эхи. Тут как раз всё просто: запрашиваем индекс фэхи, качаем нужные файлы. Пока я вижу это так:

Например, выделяем под это схемы f/

f/e/node.list вернёт что-то типа

node.list
n20170614.json:Нодлист за 14.06.2017
...
etc

Потом запрашиваем недостающие файлы

f/f/n201706.14.json

Скачиваем их и сохраняем локальный индекс.

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

Что думаете об этом вот всём? Надо ли оно? Если честно, мне эти фичи кажутся такими вкусными, что я прямо горю желанием их реализовать =)

> К сожалению, настоящим релизом я вас сегодня порадовать не могу.
> Но пусть будет хотя бы скриншот: https://ii-net.tk/screens/Screenshot_2017-06-12-22-56-49.png
> Поставленная задача с планшетной читалкой оказалась довольно сложная, и я пока что еле-еле реализовал самые базовые вещи.
> Зато фича наверняка позже себя оправдает.

О е! Шикарно смотрится. К сожалению, я только сегодня более менее оказался свободен и до сих пор не попробовал предыдущий релиз на nexbox'е. Зато перестелил родителям пол в гостиной =)

> Просто обновишься поверх, повернёшь телефон туда-сюда.

На моём телефоне не видать ничего нового.

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

Вот настройки клёво переделал. По повороту позже посмотрю.

> На 10-дюймовом девайсе оно наверняка заработает и так, без поворота.

Вот тут интересно будет посмотреть. Не уверен, что в портретном режиме это будет удобно.

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

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

> Придётся раньше времени выдавать наши секреты =)
> Борис придумал сделать в андроид-клиенте интеграцию с PGP, которую лично я себе представляю примерно так:
> При заходе в эху будет пункт меню "Настройки шифрования"
> В этих настройках пользователь указывает, что будет шифровать сообщения, отправляемые в эту эху, такими-то ключами, а расшировывать - своим таким-то.
> Механизм будет в идеале работать вообще в прозрачном режиме, вся шифровка-дешифровка будет производиться на уровне мейлера-фетчера. Шифровке подвергнется текст сообщения и сабж (мини-костылём).
> Выбор ключа и всю грязную возню с криптографией под капотом будет осуществлять свободное приложение OpenKeyChain. Оно, кстати, есть в F-Droid'е, так что за удобный GUI и юзабилити беспокоиться не надо.

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

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

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

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

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

ЗЫЖ Прости, gl00my, я так пока и не перевёл iing на sqlite.

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

Я думал сделать дополнительную схему, где по authstr отдавать только те сообщения, которые совпадают с пользователем. Снять нагрузку с клиентов, в общем. Про PGP в принципе согласен. Его лучше таки использовать, но придётся лепить удобный механизм работы с этем делом. В том числе и через веб-интерфейс. Так что хотелось бы хорошенько продумать этот вопрос.

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

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

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

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

> а также расширенный /u/e и /x/c.

Вот это дело. Самое смешное, что я их планировал, но забыл сделать. Напишу сегодня-завтра.

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

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

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

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

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

Ну буду править код под эти замечания. Не вопрос.

Изменения по мотивам предыдущего сообщения Виктора:

* f/e теперь поддерживает слайсы аналогично расширенной u/e, но пока не поддерживает несколько фэх одновременно;
* появилась схема f/c, работающая аналогично x/c;
* в индекс фэхи теперь сохраняется информация об отправителе файла.

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

Итак, последние приготовления перед пушем iing с файлэхами.

Работает это всё по трём новым схемам:

f/e/<fecho>

возвращает список файлов в фэхе (одной за запрос) в формате

имя_файла:описание

f/f/<fecho>/<filename>

скачивает нужный файл из фэхи (разные фэхи могут содержать одинаковые имена файлов).

f/p

через POST-запрос получает параметры pauth, fecho, dsc и file (строка авторизации, название фэхи, описание файла и сам файл соответственно) и сохраняет файл на узле, добавляя имя и описание в соответствующий индекс.

На уровне ФС это выглядит так:

В корне iing есть директория fecho/.

В ней есть поддиректории, соответствующие названиям фэх и индексы с именем файла <имя фэхи>.txt.

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

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

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

Не в имени фэхи, а в индексе перед именем фэхи. То есть оно будет фигурировать только в служебной информации для парсинга. Но уже всё равно. Я в предыдущем сообщении придумал более красивое решение.

> А в чем файлэхи будут кардинально отличается от текущего списка файлов? Правильно ли я понимаю, что:
> 1. Файлы смогут загружать пользователи? Если так, то тут и вправду нужно вводить ограничения. Ты же не обрадуешься, если я к тебе на сервер залью коллекцию своих любимых фильмов. И если это так, то сможет ли пользователь потом удалить файл?

Пользователи будут загружать. Удалять не смогут. Пожалуй, ты прав. Не нужно полагаться на здравый смысл пользователей =)

> 2. Файлэх может быть несколько? То есть можно будет разбить все файлы на категории: софт, музыка и т.п.?

Сколько угодно. Более того, в текущей реализации (уже на гитхабе) поинты могут создавать фэхи сами.

> 3. Будут ли они гейтоваться между станциями? То есть смогу ли сидя на одной станции получить список файлов другой станции и скачать что-нибудь?

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

ЗЫЖ Вот большие объёмы не знаю как ограничить. Административно или технически.

Безусловно ЧС будет. Без этого никак. Ну и не стоит забывать, что фэхи будут разные и не обязательно подписываться на все. Как и гейтовать.

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

Если честно, то мне видятся вполне достаточными ограничения, которые у нас на имена эх распространяются, и в этом случае. Английский алфавит с учётом регистра, цифры, минус, подчёркивание и точка.

Вот с ограничениями в описаниях у меня такой ясности мысли пока нет.

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

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

А вот, кстати. В индексе фэхи есть двоеточия, а в имени нет. Значит можно считать строку с двоеточием именем фэхи =) Всё на поверхности же.

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

За посыл в фэху 20 гигов надо карать =) Сам юзкейс фэх это передача небольших файлов.

>> Запостить файл с именем, длина которого свалит фс, вряд ли возможно, а описание вряд ли вообще может на что-то повлиять.
> Вот так и возникают уязвимости :) Ай да, и так сойдёт, как говорится ;)

Я руководствуюсь принципом Оккама. Отсекаю лишнее. Пока я не смог придумать гипотетической ситуации, которая свалит узел или клиента через длину файла или описания.

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

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

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

Двоеточие то зачем в описании запрещать? В индексе все поля фиксированы же. Выходит что-то типа того (пример на python):

f = row.split(":")
filename = f[0]
filesize = f[1]
username = f[2]
addr = f[3]
dsc = ":".join(f[4:])

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

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

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

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

На мобильном устройстве это наиболее правильное решение, ИМХО. Тот же "Горячаяя Собака Редактор", на который я уже неоднократно ссылался, вообще не поддерживает файлэхи, если мне не изменяет склероз.

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

Консенсус! =)

> В идеале надо просто непечатаемые символы удалить, а видимые - оставить. Но не знаю, как это технически реализуется.

Вот задачка. Надо будет провентилировать вопрос, но уже не сегодня.

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

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

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

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

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

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

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

Спешить же с реализацией стандарта совершенно ни к чему. Куда мы торопимся то? Джва года без файлэх жили, ещё несколько недель/месяцев проживём без проблем. Острой необходимости то нет =)

> Вот это на телефоне скрин (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

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

> Так я и не понял: один и тот же файл будет храниться на всех серверах? Я думал что только индексы будут гейтоваться, а файл останется на одном сервере. Да и на клиенте мне так же не хотелось бы автоматом выкачивать все файлы.

Так точно. Файлы ходят между всеми так же, как сообщения. На тему выкачивания, всегда можно отписаться. В условиях доступного интернета и файлообменников с торрентами, кидать в фэху музыку или не дай Босх фильмы, это моветон. Но! Для разного рода контента можно легко создавать разного рода фэхи. И не обязательно на них на всех подписываться.

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

> Идея-то неплохая, правда, злоупотреблять ей будут наверняка.

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

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

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

Начал играться с фэхами и фреками (реализовал свою мсль о том, чтобы файлы из фэх сразу попадали на фреки для поинтов). И вот что подумал: теперь уже не нужна получается схема f/f, так как файл лежит на фреках. Предлагаю упростить всё и оставить только схемы f/e для индексов и f/p для посылки файлов, а для загрузки уже использовать существующую схему x/file. Не то чтобы красиво, но зачем дублировать функционал?

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

1. Есть схемы f/e и f/p, которые необходимы для обслуживания индексов фэх и заливания файлов, соответственно.

2. Отдача файлов производится по уже существующей схеме x/file (файлы, полученные узлом по f/p автоматически попадают на фреки для поинтов).

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

Что думаете по этому поводу?

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

У меня пока в приватный складывается. Только вот gl00my (сисоп инстед-клуба) поднял вполне закономерный вопрос. В такой ситуации имя файла должно быть уникальным во всех фэхах. Надо этого каким-то образом избежать, по пути не усложнив чрезмерно реализацию.

Продолжаю думать.

Пока пришло в голову только добавление в индекс хеша содержимого файла (fileid) и сверка имени перед сохранение с автоматической подстановкой суффикса в случае необходимости.

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

Нет.

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

Именно к этому я и пришёл. Получается, UID это хеш по содержимому. А имя нода локально может и поменять (например, добавить индекс в имя перед расширением). Пока обмозговываю это. С точки зрения хранения в ФС опять таки пока не придумал как быть. Если ложить на существующий x/file, то у нас нет никакой иерархии. Только плоский список файлов. Так что или расширять имя файла именем фэхи или отказаться от x/file или усложнять x/file, что совсем не хочется.

Не было у бабы забот, так купила порося. Вот нафига я это решил делать? =)

Demon>>> Вы знаете как выложить игру в INSTEAD?
AL>> Нет.
vit01> Сказал держатель репозитория или что ты там хостишь :)

Ну не мог я удержаться. Извиняюсь =)

2Demon: Заходишь на http://instead-games.ru/, нажимаешь кнопку "Войти" (нужен google-аккаунт). После входа появится кнопка "Загрузить игру".

ЗЫЖ На моей памяти это первый раз, когда у человека возникла проблема с загрузкой игры в репозиторий.

AL>> Первое (уже озвученное ранее) это нетмейл. То есть личная переписка.
Difrex> Самое важное, ИМХО.
Difrex> Не обязательно монстрячить PGP. Можно взять AES или RSA. Обмен откртыми ключами - да, доверять сисопу. Т.е. теоритически может быть MitM.
Difrex> Нужно хотя бы драфт накидать.

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

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

Это была опечатка. Прошу пардону. Эх, а ведь вычитывал.

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

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

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

Этот индекс для автоматического фетчинга. Но добавить не долго, если он действительно нужен. Я вот думаю нафиг там имя, если есть адрес? =)

Peter> А так ли необходимо затачиваться на x/file?

По сути, x/file в стандарте описан так, что никто не мешает мою реализацию принять за стандартную =)

Зато сразу отпадает необходимость, например, пилить поддержку фэх на idec-mobile, те, что не хочет качать фэхи, но иногда хочет скачать нужный файл по запросу, опять таки уже имеют подходящий инструмент. Так что мне видится такая заточка весьма удачной.

Peter> Может таки свою схему и для забора? И по fid его?

Я изначально так и сделал, но потом с Виктором немного пообсуждали и он сказал, что будет реализовывать чтение индекса и скачивание по тапу на нужном файле. А это по сути дублирование x/file. Получение файла по fid может и имеет смысл, но тут повторю то, что уже писал в чате: в обычных эхах у нас просто нет выбора для идентификации сообщения. Только msgid. Тут же мы имеем имя фэхи и имя файла. fid же служит контрольной суммой. Пока моя схема себя оправдала на тестах, но если народ проголосует за fid, то буду мутить fid =)

Peter> Кажется, что x/file заточен на файловое хранилище определенной структуры. Хорошо ли это?

x/file заточен на определённый "протокол" обмена информацией. Как это устроено внутри - дело третье.

Пушнул текущие наработки в iing. Все желающие могут посмотреть как это работает.

После недели экспериментов и некоторых обсуждений я пришёл к кое каким мыслям.

Для функционирования файл-эх с удосбствами для тех, кто не хочет на них подписываться я несколько пофиксил x/flie. По сути, это не противоечит стандарту, но теперь filename в запросе может быть path. То есть представлять собой конструкцию вида pics/1.jpg.

Это позволяет нам содержать фреки в виде иерархии, а не плоского списка.

Схема f/e работает по тем же принципам, что и расширенная u/e.

Например, запрос f/e/pics/books/-2:2 вернёт следующее:

pics
fileid:filename:username:address:description
fileid:filename:username:address:description
books
fileid:filename:username:address:description
fileid:filename:username:address:description

Где fileid представляет собой хеш, сформированный как msgid, только по содержимому файла и служит для однозначной идентификации файла при фетчинге. Забрать же файл можно с помощью x/file.

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

Это возможно благодаря тому, что схема f/p, принимающая файлы через POST-запрос с параметрами pauth, fecho, dsc и file (строка авторизации, имя фэхи, описание файла и сам файл), сохраняет файл в директорию files/fecho/filename.

То есть при попытке отправить файл в фэху books, у нас создастся и индекс этой фэхи в формате, указанном в описании f/e и директория для фэхи в files (ежели такая отсутствует) и файл в этой директории.

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

Например, так:

pics/1.jpg:12197:Смешная картинка
pics/1_1.jpg:364649:Красивая картинка

При попытке сохранить файл, хэш которого уже есть в фэхе, возвращается ошибка (file exists). При уникальном в рамках фэхе хеше, но повторяющимся имени, нода автоматически проставляет суфикс ("_1" в примере выше). Если же "_1" уже занят, то будет проставлен "_2" и так далее. Хотя, публикация таких файлов в больших количествах уже повод для разъяснительной работы.

vit01> Вот тебе 3 различных варианта
vit01> GET /x/file/pauth/fecho.1/file1
vit01> GET /x/file/fecho.1/file2
vit01> GET /x/file/pauth/file3

Дело в том, что второй вариант не работает да. Об этом я писал несколько выше. Там, где я говорил о плоском публичном списке файлов.

vit01> Я б от этой каши (GET-API) избавился, но кроме моих скриптов и клиентов есть твои, например. Так что ты и решай.

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