#  Re: Халява, сэр!
Andrew Lobanov (tavern,1) → geomaster  –  08:17:56 2019-04-20

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

Кто-нибудь успел забрать для linnux? А то я прощёлкал всё нафиг, а от этой игры бы не отказался =)
#  Re: Халява, сэр!
Difrex (dynamic,1) → geomaster  –  07:16:40 2019-03-22

Спасибо, забрал.
#  Халява, сэр!
geomaster (mira, 23) → All  –  05:25:38 2019-03-22

На Хамбле раздают TACOMA, правда, не ключ для стима, а прямая загрузка игры. Для Linux есть.
https://www.humblebundle.com/store/tacoma
#  Re: Халява, сэр!
geomaster (mira, 23) → geomaster  –  04:58:00 2019-03-15

На хамбле раздают GRID 2
https://www.humblebundle.com/store/grid2-spa-bathurst
#  Re: idec
Difrex (dynamic,1) → Difrex  –  08:56:06 2019-03-04

Или даже так:
====
curl -XPOST -H "X-Idec-Pauth: sdlkdsfjklsdf" -T /etc/passwd idec.node/x/d/msgid
====
#  Re: idec
Difrex (dynamic,1) → Peter  –  08:21:04 2019-03-04

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

Т.е. второй запрос будет выглядеть как-то так:
====
curl -XPOST -d "pauth=sdlkdsfjklsdf" -d "xdata=$(cat /etc/passwd)" http://idec.node/x/d/msgid
====
#  Re: idec
Peter (syscall,1) → Peter  –  08:09:22 2019-03-04

В общем, доп запрос все таки это тоже усложнение.:( Если он не атомарный, то надо помнить сообщения для которых мы не забрали блоб. Если атомарный - усложнение логики ноды. Надо думать.:(
#  Re: idec
Peter (syscall,1) → Peter  –  08:03:58 2019-03-04

Хотя я сейчас подумал, что дополнительный запрос и для общения нод проблема. Допустим на первой итерации забрал все msgid и собираюсь забирать блобы. По идее я эти сообщения должен отдавать уже или нет? Если отдам, то другая нода не получит блоб. С другой стороны, она его получит на след синке. Гм...
#  Re: idec
Peter (syscall,1) → Difrex  –  07:50:38 2019-03-04

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

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

Поэтому пока ничего, кроме расширения текущего post я не могу придумать. Ну типа если в заголовке есть xdata ждём поток после сообщения из этого количества байт. В принципе тогда и совместимость останетс, и все ещё достаточно просто.
#  Re: idec
Andrew Lobanov (tavern,1) → vit01  –  04:36:46 2019-03-04

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

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

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

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

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

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

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


>> Читать далее
#  Re: idec
Difrex (dynamic,1) → Peter  –  21:23:52 2019-03-03

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

Как со стороны клиента должен выглядеть аплоад?
#  Re: idec
vit01 (mira, 1) → Andrew Lobanov  –  21:22:04 2019-03-03

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

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

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

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

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

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

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
#  Re: idec
vit01 (mira, 1) → Andrew Lobanov  –  21:09:12 2019-03-03

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

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

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

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

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

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
#  Re: idec
Peter (syscall,1) → Peter  –  19:45:32 2019-03-03

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

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

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

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

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

Так что для этих доп данных я придумал бы все таки что то простое, но все-таки допускающее задание ключ = блоб...
#  Re: idec
Peter (syscall,1) → Andrew Lobanov  –  19:10:57 2019-03-03

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

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

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

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

Я бы, конечно, предложил что то вроде key = value, но это вообще не важно.
#  Re: idec
Andrew Lobanov (tavern,1) → Difrex  –  19:04:25 2019-03-03

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

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

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


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

На тему того, что не обязательно это должен быть файл, я хочу заметить, что пользователям не нужны абстрактные сферические данные. Им нужны файлы =)
#  Re: idec
Andrew Lobanov (tavern,1) → Difrex  –  18:58:56 2019-03-03

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

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

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

Не. Мою идею уже разгромили все, кому не лень. Подожду когда предложат чего получше =)
#  Re: idec
Difrex (dynamic,1) → Andrew Lobanov  –  18:49:25 2019-03-03

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

Подумал над этим - да, наверное действительно проблемы нет. Нужно колличество байт только писать. Это не сложно, т.к. нода это знать должна при приеме данных.
#  Re: idec
Difrex (dynamic,1) → Andrew Lobanov  –  18:34:30 2019-03-03

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

> Давай просто накидаем что и как должно быть и посмотрим насколько оно будет юзабельно
Так давай! Пили PoC :)
#  Re: idec
Difrex (dynamic,1) → Difrex  –  18:36:25 2019-03-03

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

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