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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

f/e/<fecho>

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

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

f/f/<fecho>/<filename>

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

f/p

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

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

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

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

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

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

AL> Пользователи будут загружать. Удалять не смогут.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

К сожалению потестить не смогу, т.к. нет планшета, но хотелось бы.

vit01> 1. последнее прочитанное (в обычных эхах) выделяется цветом
vit01> 2. включена автопрокрутка до последнего прочитанного

Класс, стало гораздо информативнее.

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

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

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

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

>> В случае файлэхи не очень понятен юзкейс для которого это поле нужно. Можно поподробнее?
> Не, ну ты чё. Скачивать файл 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:])

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Должен быть список разрешённых символов. Он будет всяко меньше списка запрещённых и работать быстрее.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот это на телефоне скрин (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, потому что на основном девайсе семёрка. Ну и для подстраховки таскаю его на дачу (на тот случай, если мобила разрядилась). А так его мать юзает, чтобы кинцо всякое разное смотреть.

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

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

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

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

vit01> А ещё в 7 андроиде (да и в 6 тоже) можно менять масштаб изображения на экране в системных настройках.

Не нашел такого у себя в 6-ке, видимо в стандартной прошивке этого нет.

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

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

> Вот это на телефоне скрин (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. Исправлена регрессия с неработающей навигацией по repto
2. Учтены пожелания Бориса по "логичности" открытия списка сообщений
3. Поправлен текст предупреждения о доступе к памяти (чтобы не путать народ насчёт SD-карты)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нет.

Имхо, имя файла имеет смысл только при записи его клиентом себе на диск. Во всех остальных случаях ключ -- это хеш контента.
В этом смысле, обмен файлами не сильно отличается от обменом сообщениями. Но я пока не могу придумать ничего конкретного. Если появятся идеи -- напишу. В принципе, у нас 2 типа информации. 1- сам бинарный блоб и 2- метаинформация (размер, имя файла, mime???). Имхо все это может быть частью одного "сообщения". Ну почти как наши текущие :)

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

AL> Нет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 заточен на определённый "протокол" обмена информацией. Как это устроено внутри - дело третье.

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

Самое важное, ИМХО.
Не обязательно монстрячить PGP. Можно взять AES или RSA. Обмен откртыми ключами - да, доверять сисопу. Т.е. теоритически может быть MitM.

Нужно хотя бы драфт накидать.