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

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

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

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

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

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

> GET /x/file/pauth/filename

> fileid:filename:username:address:description

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

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

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

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

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

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

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

AL> Тут нет двоеточия. Это я наподобии бутылковых маршрутов написал. @route("x/file/"), что означает, что принимается 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> Теоретически мне без разницы адрес там или Имярек Имярекович с адресом. Мы будем знать какого сисопа пинать в обоих случаях.

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

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

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

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

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

fid:filename:size:address:description