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

Схема f/c работает по аналогии с x/c, но только для фэх.

Например, f/c/books/pics


Схема f/e работает по аналогии с расширенной u/e, но только для фэх. Возвращает индекс в следующем формате:

hash:filename:size:address:description,

где hash это хеш содержимого файла по алгоритму генерации msgid;
filename - имя файла (ограничения по символам такие же, как и на эхи; по длинне 60 символов);
size - размер файла в байтах;
address - адрес отправителя (nodename, point);
description - однострочное описание файла (ограничени по длинне 1 килобайт).

Например, f/e/books/pics/-5:5


Схема f/f принимает в качестве параметров имя фэхи и хеш файла и возвращает файл.

Например, f/f/books/ansicl.pdf


Схема f/p принимает через POST-запрос параметры pauth, fecho, file и dsc и сохраняет файл в фэху.
----
Подробности реализации в спецификацию забивать не хочу, но технически у меня файлы попадают во фреки.


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

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

Ну так я и не писал, что длину оставляем ту же. Но против 120 символов я тоже ничего не имею =)

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

f/f позволяет качать без авторизации. Свободный фетчинг у нас же. Так что для целостности концепции. Да и как-то красивее это. А то одна дополнительная сущность начинает зависеть от другой дополнительной сущности. А то, что файлы у меня сыпаются в x/file это приятный бонус, который я не хотел бы делать частью стандарта, если честно.

Однако, готов рассмотреть варианты да =)

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