vit01>> Насчёт лимита в 64 килобайта я против :)

AL> В общем, предлагаю компромисс: ограничение делать, но килобайт в 256-512. Я за последнее =)

У меня в 512к лимит в nginx стоит.

+++ картошки хватит на всех

Андрей попросил меня высказаться по вопросу.

Но прежде чем я это сделаю, я должен сказать, что мое мнение не стоит воспринимать как мнение полноценного участника idec, влияющего на его стандарты.
Почему? Потому что у меня очень своеобразное чувство прекрасного, в чем мы уже успели убедиться на примере споров о нетмыле.
И кроме того, я вряд ли буду внедрять в свою ноду фичи, которые мне тяжело делать или они мне покажутся неправильными/не нужными.

Короче, вес моего мнения не должен быть высоким.

Ну а теперь по фичам =)

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

2) Стандарт имхо должен явно содержать в себе указание на размер сообщений ГАРАНТИРОВАННО пропускаемой нодой. Ну например, любая нода должна в состоянии обработать 64кб сообщения. Насчет размера. Я бы не стал делать его > 128кб.

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

4) idec должен оставаться простой. поэтому мне не нравится идея с подписями вообще (хотя я сам предложил +++). Но так как для меня это просто часть сообщения -- это норм. Но я вижу, что теперь речь уже заходит в сторону того, что они мешают поиску. И их надо как то там парсить =) Хранить в отдельной БД. В общем, это все усложнение изначально простой идеи. Я однозначно против. Я бы вообще из стандарта исключил подписи. =)

В общем, как видите, я не тот человек, к мнению которого надо прислушиваться. Если бы я делал idec с нуля я бы:

- выбрал бы подмножество markdown для разметки;
- выкинул бы большинство расширений;
- ввел бы типизацию сообщений так, чтобы можно было фигачить картинки файлы итд. а умные клиенты могли бы игнорировать нежелательный контент (качать только заголовки)
- сделал бы netmail примерно как у меня это сделано на ноде (как часть существующего протокола, а не как новая вещь).

НО! Я этого всего никогда делать не буду, просто Андрей спросил - я ответил развернуто. Потому что одно цепляется за другое. Вопрос размера -- не висит в пустоте =)

Еще раз конкретно по вопросу ограничения. Ограничение нужно. 64кб или 128кб. 256 уже перебор. Но само число не так важно, так как длинные статьи и книни все равно надо или разбивать на части или в фехи (которые моя нода не поддерживает =)

vit01>>> Насчёт лимита в 64 килобайта я против :)
AL>> В общем, предлагаю компромисс: ограничение делать, но килобайт в 256-512. Я за последнее =)
Difrex> У меня в 512к лимит в nginx стоит.

Ну так оно нормально как бы ещё.

Вообще, странно в 2019 бояться сообщений длиннее 64к. Я понимаю почему это есть в фидо (там куча узлов на автопилоте, которые никто не трогал толком с 90-х, когда это ограничение было необходимостью в связи с каналами и объёмами домашних винтов), но тут и сейчас не понимаю. То есть гигабайтные сообщения это, безусловно, бред, но хотя бы полумегабайтные это нормально.

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

Понял, что мутновато выразился.

Короче. Я бы разделил транспорт от того что этот транспорт переносит.
Есть простой протокол обмена сообщениями. КАКИЕ ИМЕННО сообщения - дб пофиг.
А мы лепим свой протокол на фехи, свой на нетмыло итд итп. Расширения =) Не, это не KISS =)

Но и текущая реализация меня устраивает. Техническая сторона вопроса вообще -- вторична.

> Нужна помощь!

> Не мне.

> Подробности тут: https://www.linux.org.ru/forum/talks/14713493

Не выжил Рома. :(

Peter> Не выжил Рома. :(

Земля пухом...

Peter> Не выжил Рома. :(
Был один из немногих участников ЛОРа, которого было интересно и приятно читать. RIP.

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

Про захавание всего коммерческими сетьми )
Недавно заМаячился и набрался оттуда всяких знаний.
Вот сюжет на тему: https://radiomayak.ru/videos/video/id/1859454/
Решил приволочь его сюда, т.к. тема близка

В Steam стартовала раздача хоррора Kholat.
Сюжет игры вдохновлён происшествием с туристической группой Дятлова в 1959 году, когда на Северном Урале при не выясненных до конца обстоятельства погибло девять человек.

Чтобы забрать хоррор, нужно добавить его к себе в библиотеку — игра останется там навсегда. Акция продлится до 4 февраля.
https://store.steampowered.com/app/343710/Kholat/

К сожалению, игра только под win.

Недавно прокуратура решила реанимировать расследование этого происшествия.

Версию убийства они сразу исключили, оставив три, которые связаны с рахными несчастными случаями.

Даже не знаю, как сказать.. На фоне Арашуковых и им подобных эта инициатива выглядит блажью.

На HumbleBundle раздают Депонию
https://www.humblebundle.com/store/deponia-the-complete-journey

Peter> Не выжил Рома. :(
Да, очень печально. На редкость адекватный человек был.

+++ At work. idec.el/0.1

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

С одной стороны, конечно, если отказываться от фэх и фреков, то это опять ломать софт на куче станций. Зато будем иметь более элегантное архитектурное решение. К тому же можно переходить на это плавно, так как оно не ломает совместимость с ii и с idec.

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

Звучит интересно!

Если это лучше, чем фэхи, то я запилю у себя реализацию.

AL> Тут Пётр предложил идейку, которая позволит прилеплять дополнительные данные к сообщениям. Так станут ненужными ни фэхи ни фреки. Я пока в свободное время, коего очень немного, попиливаю концепт этого дела. Как будет что показать, выложу на поиграться в свободный доступ.
Кстати, а может озвучишь идейку саму? :)

+++ At work. idec.el/0.1

AL>> Тут Пётр предложил идейку, которая позволит прилеплять дополнительные данные к сообщениям. Так станут ненужными ни фэхи ни фреки. Я пока в свободное время, коего очень немного, попиливаю концепт этого дела. Как будет что показать, выложу на поиграться в свободный доступ.
Difrex> Кстати, а может озвучишь идейку саму? :)

Да чего ж не озвучить?

У нас в сообщениях есть теги. И мы их используем только для хранения repto. Можно добавить туда некую метку, например "xdata".

Фетчер тоссит сообщение, видит метку и добавляет msgid в список сообщений с дополнительными данными. После того, как растоссил, передаёт айдишники в какую-нить схему типа x/d/<msgids>.

Нода на запрос возвращает что-нить типа:

<msgid>:<type>:<data>

Например

gkCo68TG1nrIXrgMklUN:filename:image.jpg
gkCo68TG1nrIXrgMklUN:image:<base64 картинки>

Тоссер это всё скачивает, распаковывает и сохраняет.

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

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

>Несколько файлов, например
Вот этот момент не очень ясен. Т.е. в теги ты предлагаешь запихить что-то типа?

ii/ok/repto/C0oZ2QgNoKfO3kFiAWop/xdata/BASE64(image)/xdata/BASE64(gpg signature)

На сколько большими можно делать такие аттачи? Картинки довольно много весят, например.

>Оно выглядит как гораздо более органичное развитие ii, нежели фэхи.
Согласен, что это выглядит намного лучше, чем файловые эхи, которых у меня, кстати, нет :).

>> Несколько файлов, например
Difrex> Вот этот момент не очень ясен. Т.е. в теги ты предлагаешь запихить что-то типа?
Difrex> ====
Difrex> ii/ok/repto/C0oZ2QgNoKfO3kFiAWop/xdata/BASE64(image)/xdata/BASE64(gpg signature)
Difrex> ====
Difrex> На сколько большими можно делать такие аттачи? Картинки довольно много весят, например.

В теги просто проставляется метка. Типа так:

ii/ok/repto/C0oZ2QgNoKfO3kFiAWop/xdata

Её наличие даёт клиенту информацию, что для этого сообщения есть аттачи. То есть последовательность такая:

1. Качаем сообщения через u/e и u/m.
2. Тоссим их. В процессе запоминаем в каких сообщениях есть метка.
3. Запрашиваем аттачи.

>> Оно выглядит как гораздо более органичное развитие ii, нежели фэхи.
Difrex> Согласен, что это выглядит намного лучше, чем файловые эхи, которых у меня, кстати, нет :).

Ну фэхи были сбоку по аналогии с фидонетом, где всё сбоку.

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

> В теги просто проставляется метка
Тогда, как заливать аттач вместе с постом?
Расширять стандартное АПИ, чтобы принимало файлики или сразу постить
в /x/d?

* ii://RAvybDSreADX2RiJXr2c
> Зачем третий запрос?
Да, получается, что два. Неправльно понял, как оно предпологается.
На схемке есть двойная стрелка, которая, символизирует два запроса :)

> Клиент видит тэг, запрашивает все аттачи по этому тегу
Вот это не нравится. А если я не хочу все аттачи тянуть?

>> В теги просто проставляется метка
Difrex> Тогда, как заливать аттач вместе с постом?
Difrex> Расширять стандартное АПИ, чтобы принимало файлики или сразу постить
Difrex> в /x/d?
Difrex> * ii://RAvybDSreADX2RiJXr2c

Пока в процессе это всё. Хочу и так и этак попробовать, а там уже смотреть.

>> Клиент видит тэг, запрашивает все аттачи по этому тегу
Difrex> Вот это не нравится. А если я не хочу все аттачи тянуть?

Тогда просто игнорируешь тег и всё.

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

AL> В теги просто проставляется метка. Типа так:

AL> ====
AL> ii/ok/repto/C0oZ2QgNoKfO3kFiAWop/xdata
AL> ====

Надо в виде xdata/3 (3 файла в аттачах) или хотя бы xdata/4096 (общий размер вложений в байтах)

Потому что
1. Парсеры тегов в наших клиентах устроены так, что тег записывается в виде key/value, и нарушение такой симметрии испортит добавление новых тегов в будущем

2. Знать размер файлов вложений полезно ещё до того как делать второй запрос.

Difrex>> Не, мне кажется, что нужно что-то сделать для того, чтобы можно было по одному аттачу качать.

AL> Тогда лишний запрос надыть. Или в теги писать метаданные аттачей, что можно, но чревато большими тегами.

Однозначно лишний запрос. Не хочу скачивать на свою мобилку кота в мешке на 100 мегабайт через платный лимитированный трафик.

Peter> Ой, моя реплика относилась к идее делать несколько тегов на каждый тип. Ну типа тег - картинка, тег - архив. Что-то ещё.. Тогда мы должны делать все эти n запросов. Да ещё и выбирать, что пропускать... Вот это, кмк, будет хуже текущих фрек.

На каждый тип файла делать свой костыль однозначно НЕ надо. Типа image, archive, music и.т.д. Расширения файла вполне достаточно, чтобы клиент распознал, что с файлом делать. Вдруг человеку захочется отправить какой-нибудь исполняемый или другой экзотический бинарник. Что, ради этого стандарт править?

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

AL>> В теги просто проставляется метка. Типа так:

AL>> ====
AL>> ii/ok/repto/C0oZ2QgNoKfO3kFiAWop/xdata
AL>> ====

vit01> Надо в виде xdata/3 (3 файла в аттачах) или хотя бы xdata/4096 (общий размер вложений в байтах)
vit01> Потому что
vit01> 1. Парсеры тегов в наших клиентах устроены так, что тег записывается в виде key/value, и нарушение такой симметрии испортит добавление новых тегов в будущем

Нет.

vit01> 2. Знать размер файлов вложений полезно ещё до того как делать второй запрос.

Вот это полезно может быть.

Difrex>>> Не, мне кажется, что нужно что-то сделать для того, чтобы можно было по одному аттачу качать.
AL>> Тогда лишний запрос надыть. Или в теги писать метаданные аттачей, что можно, но чревато большими тегами.
vit01> Однозначно лишний запрос. Не хочу скачивать на свою мобилку кота в мешке на 100 мегабайт через платный лимитированный трафик.

Если размер в тег кинуть, то и не скачаешь. И вообще сделать это для клиента делом добровольным.

Peter>> Ой, моя реплика относилась к идее делать несколько тегов на каждый тип. Ну типа тег - картинка, тег - архив. Что-то ещё.. Тогда мы должны делать все эти n запросов. Да ещё и выбирать, что пропускать... Вот это, кмк, будет хуже текущих фрек.
vit01> На каждый тип файла делать свой костыль однозначно НЕ надо. Типа image, archive, music и.т.д. Расширения файла вполне достаточно, чтобы клиент распознал, что с файлом делать. Вдруг человеку захочется отправить какой-нибудь исполняемый или другой экзотический бинарник. Что, ради этого стандарт править?

Зачем городить? file сделать и всё =)

vit01> +++ Отправлено через IDEC Mobile
vit01> +++ GNU/Linux, Android, physics, MLP:FIM

vit01>> 1. Парсеры тегов в наших клиентах устроены так, что тег записывается в виде key/value, и нарушение такой симметрии испортит добавление новых тегов в будущем

AL> Нет.

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

Ну или хотя бы прошу сделать что-то вроде /xdata/null/ или /xdata/1, чтобы при перестановке значений в тегах между собой данные обрабатывались единообразно.

vit01>> Однозначно лишний запрос. Не хочу скачивать на свою мобилку кота в мешке на 100 мегабайт через платный лимитированный трафик.

AL> Если размер в тег кинуть, то и не скачаешь. И вообще сделать это для клиента делом добровольным.

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

А вот если перед нажатием кнопки "скачать" человек будет сразу видеть hot_naked_black_men.jpg (5 МБ), то тогда у него действительно появится выбор, качать или нет.

vit01>> На каждый тип файла делать свой костыль однозначно НЕ надо. Типа image, archive, music и.т.д. Расширения файла вполне достаточно, чтобы клиент распознал, что с файлом делать. Вдруг человеку захочется отправить какой-нибудь исполняемый или другой экзотический бинарник. Что, ради этого стандарт править?

AL> Зачем городить? file сделать и всё =)

Цитирую:

AL> Например:

> ====
> image:<filename>:<base64>
> audio:<filename>:<base64>
> ====

Не надо всяких image и audio, это избыточно и городит мусор с костылями в стандарте. Достаточно просто filename:base64

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

Надо уже выкидывать всё к чертям из стандарта. Реально полезным оказался только расширенный u/e. Остальное никому не впилось и все старательно не поддерживают эти фичи. Аттачи или изуродуем и раздуем, что сразу сделает их не лучше фэх, или не реализуем вовсе. Так что брошу я это дело. Файлы можно и в ТГ кинуть кому надо.

Секта просрана. Люди боятся людей даже в таком маленьком обществе.

> Реально полезным оказался только расширенный u/e.
x/c еще все используют. И u/m.

Зря ты так.
Я, например, думаю, что xdata на конце достаточно. Но должен быть еще один запрос, чтобы узнать, что там в данных. Например, я не хочу качать какие-то непонятные elf если они вдруг будут.
Я на самом деле за то, чтобы один пост - одно вложение, да и все.
И уж точно не как filename:base64data отдавать контент.

>> Реально полезным оказался только расширенный u/e.
Difrex> x/c еще все используют. И u/m.

Ну да. x/c ещё так как без него расширенный u/e бесполезен. u/m ничем у нас от ii не отличается.

Difrex> Зря ты так.
Difrex> Я, например, думаю, что xdata на конце достаточно. Но должен быть еще один запрос, чтобы узнать, что там в данных. Например, я не хочу качать какие-то непонятные elf если они вдруг будут.
Difrex> Я на самом деле за то, чтобы один пост - одно вложение, да и все.
Difrex> И уж точно не как filename:base64data отдавать контент.

Это всё слишком много. Проще выкинуть, чем делать. Кому надо столько запросов да на каждое сообщение?

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

> Кому надо столько запросов да на каждое сообщение?
Не на каждое, а на то, которое с тегом ^_^

> Давай просто накидаем что и как должно быть и посмотрим насколько оно будет юзабельно
Так давай! Пили PoC :)

Я примерно представляю уже как впилить реализацию у себя в ноде, только сначала
подожду твоей.

Этож у нас МЕМАСИКИ появятся :).

>> Кому надо столько запросов да на каждое сообщение?
Difrex> Не на каждое, а на то, которое с тегом ^_^

Ну это да, но всё равно чёт стрёмно.

>> Давай просто накидаем что и как должно быть и посмотрим насколько оно будет юзабельно
Difrex> Так давай! Пили PoC :)

Не. Мою идею уже разгромили все, кому не лень. Подожду когда предложат чего получше =)

> решением с обязательным скачиванием (тут я не вижу проблемы)

Подумал над этим - да, наверное действительно проблемы нет. Нужно колличество байт только писать. Это не сложно, т.к. нода это знать должна при приеме данных.

>> решением с обязательным скачиванием (тут я не вижу проблемы)
Difrex> Подумал над этим - да, наверное действительно проблемы нет. Нужно колличество байт только писать. Это не сложно, т.к. нода это знать должна при приеме данных.

Ну вот. Можно что-то типа тега

xdata/<filename>:<filesize>

заюзать и действительно ограничить на один файл на сообщение.

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

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

Это дело пользователей, а не ноды. В этом и была принципиальная новизна моей идеи. :)
Мы можем считать это tar. Можем считать это сборником строк: key=value (base64)

Это просто метаданные, связанные с msgid. Ноды просто могут пропускать их через себя через 1 доп запрос.

Как их визуализировать и воспринимать - не дело стандарта. :) Дело клиента.

Я бы, конечно, предложил что то вроде key = value, но это вообще не важно.

Короче, если инженерно, то это тег, ну пусть xdata/размер в байтах.
Этот блоб мы как нода фетчим за 1 доп запрос на сообщение.

А теперь клиенты(в том числе и веб).

Если это будет просто файл, то можно конечно, но как это определит софт? Что там, картинка или видосик? Поэтому я и думал, что в общем случае там мб какой то простой контейнер.

Ну смотрите, у нас же сообщение в определенном формате? Вот и тут, некий универсальный формат но допускающий бинарные данные.

Зачем? Не нарушена совместимость с ii. Старый софт пропустит текст, но не пропустит котика. И логическая сущность останется одна -- сообщение с msgid.

Так что для этих доп данных я придумал бы все таки что то простое, но все-таки допускающее задание ключ = блоб...

AL> Ну вот. Можно что-то типа тега

AL> ====
AL> xdata/<filename>:<filesize>
AL> ====

Вот, это предложение уже конструктивно.

AL> заюзать и действительно ограничить на один файл на сообщение.

Да можно туда и несколько файлов засунуть.
xdata/filename1:filesize1:filename2:filesize2 и так далее

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

AL> Надо уже выкидывать всё к чертям из стандарта. Реально полезным оказался только расширенный u/e. Остальное никому не впилось и все старательно не поддерживают эти фичи. Аттачи или изуродуем и раздуем, что сразу сделает их не лучше фэх, или не реализуем вовсе. Так что брошу я это дело. Файлы можно и в ТГ кинуть кому надо.

AL> Секта просрана. Люди боятся людей даже в таком маленьком обществе.

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

Если кто-нибудь не хочет фэхи (или другой подобный протокол) на станции из-за опасений "нехорошего" контента, то он и так, и эдак их поддерживать не будет.

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

Нетмейл нам нужен в каком-то смысле, но вряд ли у меня будет хватать смекалки и времени самому продумать, как это дело может работать. Но, тем не менее, его надо бы реализовать.

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

> Этот блоб мы как нода фетчим за 1 доп запрос на сообщение.
Это когда с другой годы тянем данные.

Как со стороны клиента должен выглядеть аплоад?

AL>> Секта просрана. Люди боятся людей даже в таком маленьком обществе.
vit01> Зря ты так, зачем обижаться?

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

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

Можно и подумать.

vit01> Если кто-нибудь не хочет фэхи (или другой подобный протокол) на станции из-за опасений "нехорошего" контента, то он и так, и эдак их поддерживать не будет.

Конечно. Я ж не про то.

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

Петру нужно место для общения про инстед. Он и сделал такое место. Бонных фэх у нас нет и это в текущих реалиях правильно.

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

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

Difrex> Как со стороны клиента должен выглядеть аплоад?

Тут, скорее всего, не получится сделать это 2м независимым запросом. Так как запросы разделены во времени и нам нельзя писать его в базу (или отдавать другим нодам) пока все не будет залито.

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

Хотя я сейчас подумал, что дополнительный запрос и для общения нод проблема. Допустим на первой итерации забрал все msgid и собираюсь забирать блобы. По идее я эти сообщения должен отдавать уже или нет? Если отдам, то другая нода не получит блоб. С другой стороны, она его получит на след синке. Гм...

В общем, доп запрос все таки это тоже усложнение.:( Если он не атомарный, то надо помнить сообщения для которых мы не забрали блоб. Если атомарный - усложнение логики ноды. Надо думать.:(

> Поэтому пока ничего, кроме расширения текущего post я не могу придумать. Ну типа если в заголовке есть xdata ждём поток после сообщения из этого количества байт
Авторизация должна оставаться.

Т.е. второй запрос будет выглядеть как-то так:

curl -XPOST -d "pauth=sdlkdsfjklsdf" -d "xdata=$(cat /etc/passwd)" http://idec.node/x/d/msgid

Или даже так:

curl -XPOST -H "X-Idec-Pauth: sdlkdsfjklsdf" -T /etc/passwd idec.node/x/d/msgid

На хамбле раздают GRID 2
https://www.humblebundle.com/store/grid2-spa-bathurst

На Хамбле раздают TACOMA, правда, не ключ для стима, а прямая загрузка игры. Для Linux есть.
https://www.humblebundle.com/store/tacoma

Спасибо, забрал.

geomaster> На Хамбле раздают TACOMA, правда, не ключ для стима, а прямая загрузка игры. Для Linux есть.
geomaster> https://www.humblebundle.com/store/tacoma

Кто-нибудь успел забрать для linnux? А то я прощёлкал всё нафиг, а от этой игры бы не отказался =)

Я забрал. В понедельник кину ссылкой

Архив с игрой тут
https://mega.nz/#!gE1XCaxb!uvv3hG4mb8SohoBRHfEeGi9QI_QMG8Xe-ItJZA_n45M

Кто то пользуется/присутствует там? Может быть это и есть адекватная замена жабберу?