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

Для функционирования файл-эх с удосбствами для тех, кто не хочет на них подписываться я несколько пофиксил 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" и так далее. Хотя, публикация таких файлов в больших количествах уже повод для разъяснительной работы.

Интересно.
А так ли необходимо затачиваться на x/file?
Может таки свою схему и для забора? И по fid его?
Кажется, что x/file заточен на файловое хранилище определенной структуры. Хорошо ли это?

>> Например 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 выдавался размер файла в байтах. Мы уже говорили по этому поводу. Нельзя никак качать котов в мешке, пусть даже сейчас мы и предполагаем, что файлы мелкие будут. Это сейчас они мелкие, а потом - крупные.

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

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 выдавался размер файла в байтах. Мы уже говорили по этому поводу. Нельзя никак качать котов в мешке, пусть даже сейчас мы и предполагаем, что файлы мелкие будут. Это сейчас они мелкие, а потом - крупные.

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

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

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

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

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

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

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

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

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, и народ с чужих станций (не таверны) должен будет догадываться, Вася загрузил файл или Петя.

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) избавился, но кроме моих скриптов и клиентов есть твои, например. Так что ты и решай.

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

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

Спасибо. В свою очередь я внёс эти исправления в iing.

Так же. Не взирая на то, что фэхи хорошо легли на фреки, вернул схему f/f.

Работает это так: f/f/<fecho>/<fid> возвращает файл. Нужно это для получения фэхи без авторизации на аплинке. так как у нас такой фигни не было, то незачем и привносить.

fid генерируется тем же алгоритмом, что и msgid, только по содержимому файла (или я об этом уже писал?).

В гите уже новая версия iing с новой версией фетчера, учитывающего фэхи. Пока для тестирования, конечно.

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

Убедил.

AL>> x/file/filename, x/file/pauth/filename:path не пересекаются.
vit01> // Тогда уж path:filename.
vit01> Окей, это уже сойдёт. Совместимость всё равно поломалась немного (не все ФС поддерживают двоеточия в имени файла), но такой формат будет самым приемлемым в долгосрочной перспективе.

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

AL>> Я вот думаю нафиг там имя, если есть адрес? =)
vit01> Вот получили файл от какого-нибудь 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> Теоретически мне без разницы адрес там или Имярек Имярекович с адресом. Мы будем знать какого сисопа пинать в обоих случаях.

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