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

Это когда с другой годы тянем данные.

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

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

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

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

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