здесь обсуждаем разработку

А протокол (формат) обмена между нодами существует? Хочу запилить ноду на холодильнике.

продолжение:

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

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

https://www.ics.uci.edu/~eppstein/pubs/EppGooUye-SIGCOMM-11.pdf
это как раз про наш случай.

IyAtKi0gY29kaW5nOiB1dGYtOCAtKi0KCmZyb20gYm90dGxlIGltcG9ydCAqCmltcG9ydCBiYXNl
NjQsIHpsaWIsIG9zCgpkZWYgX3JmKGYpOiAKICAgIGlmIG9zLnBhdGguZXhpc3RzKGYpOiByZXR1
cm4gb3BlbihmKS5yZWFkKCkKICAgIGVsc2U6IHJldHVybiAnJwoKZGVmIHJhd19tc2coaCk6CiAg
ICByZXR1cm4gX3JmKCdtc2cvJXMnICUgaCkKCmRlZiBnZXRfZWNob2FyZWEobmFtZSk6CiAgICBy
ZXR1cm4gX3JmKCdlY2hvLyVzJyAlIG5hbWUpLnNwbGl0bGluZXMoKQoKZGVmIG1rX2p0KG1oLG1i
KToKICAgIHJldHVybiBtaCArICc6JyArIGJhc2U2NC51cmxzYWZlX2I2NGVuY29kZSggemxpYi5j
b21wcmVzcyhtYikgKQoKZGVmIHF1YShlYSxzKToKICAgIGl0ZW1zID0gIGdldF9lY2hvYXJlYShl
YSkKICAgIGlmIGxlbihzKSA8IDYgYW5kIHMuaXNkaWdpdCgpOgogICAgICAgIHJldHVybiBpdGVt
c1staW50KHMpOl0KICAgIGVsc2U6CiAgICAgICAgaWYgbm90IHMgaW4gaXRlbXM6IHJldHVybiBp
dGVtcwogICAgICAgIHJldHVybiBpdGVtc1tpdGVtcy5pbmRleChzKSsxOl0KCmRlZiBwYXJzZV9l
Y2hvcyhlY2hvcyk6CiAgICBwb29sID0gW10KICAgIGZvciBlYSBpbiBlY2hvczoKICAgICAgICBp
ZiAnOicgaW4gZWE6CiAgICAgICAgICAgIGl0ZW1zID0gcXVhKCplYS5zcGxpdCgnOicsMSkpCiAg
ICAgICAgZWxzZToKICAgICAgICAgICAgaXRlbXMgPSBnZXRfZWNob2FyZWEoZWEpCiAgICAgICAg
Zm9yIHggaW4gaXRlbXM6CiAgICAgICAgICAgIGlmIG5vdCB4IGluIHBvb2w6CiAgICAgICAgICAg
ICAgICBwb29sLmFwcGVuZCh4KQogICAgcmV0dXJuIHBvb2wKCgpAcm91dGUoJy96L20vPGg6cGF0
aD4nKQpkZWYganRfb3V0bXNnKGgpOgogICAgcmVzcG9uc2Uuc2V0X2hlYWRlciAoJ2NvbnRlbnQt
dHlwZScsJ3RleHQvcGxhaW47IGNoYXJzZXQ9dXRmLTgnKQogICAgcmV0dXJuICdcbicuam9pbigg
W21rX2p0KHgscmF3X21zZyh4KSkgZm9yIHggaW4gaC5zcGxpdCgnLycpIGlmIGxlbih4KT09MjBd
ICkgKyAnXG4nCgpAcm91dGUoJy96L2UvPG5hbWVzOnBhdGg+JykKZGVmIGluZGV4X2xpc3QobmFt
ZXMpOgogICAgcmVzcG9uc2Uuc2V0X2hlYWRlciAoJ2NvbnRlbnQtdHlwZScsJ3RleHQvcGxhaW47
IGNoYXJzZXQ9dXRmLTgnKQogICAgb3V0ID0gJycKICAgIGZvciBlYSBpbiBuYW1lcy5zcGxpdCgn
LycpOgogICAgICAgIG91dCArPSBlYSArICdcbicKICAgICAgICBnZSA9IGdldF9lY2hvYXJlYShl
YSkKICAgICAgICBpZiBnZTogb3V0ICs9ICdcbicuam9pbihnZSkgKyAnXG4nCiAgICByZXR1cm4g
b3V0CgpAcm91dGUoJy96L2dldC88ZWNob3M6cGF0aD4nKQpkZWYganRfZWNobyhlY2hvcyk6CiAg
ICByZXNwb25zZS5zZXRfaGVhZGVyICgnY29udGVudC10eXBlJywndGV4dC9wbGFpbjsgY2hhcnNl
dD11dGYtOCcpCiAgICByZXR1cm4gJ1xuJy5qb2luKCBbbWtfanQoeCxyYXdfbXNnKHgpKSBmb3Ig
eCBpbiBwYXJzZV9lY2hvcyhlY2hvcy5zcGxpdCgnLycpKV0gKSArICdcbicKCkByb3V0ZSgnL20v
PG1zZz4nKQpkZWYgZ2V0X21zZyhtc2cpOgogICAgcmVzcG9uc2Uuc2V0X2hlYWRlciAoJ2NvbnRl
bnQtdHlwZScsJ3RleHQvcGxhaW47IGNoYXJzZXQ9dXRmLTgnKQogICAgcmV0dXJuIHJhd19tc2co
bXNnKQoKQHJvdXRlKCcvZS88ZWNob2FyZWE+JykKZGVmIGdldF9lY2hvbGlzdChlY2hvYXJlYSk6
CiAgICByZXNwb25zZS5zZXRfaGVhZGVyICgnY29udGVudC10eXBlJywndGV4dC9wbGFpbjsgY2hh
cnNldD11dGYtOCcpCiAgICByZXR1cm4gJ1xuJy5qb2luKCAgZ2V0X2VjaG9hcmVhKGVjaG9hcmVh
KSApICsgJ1xuJwoKcnVuKGhvc3Q9JzEyNy4wLjAuMScscG9ydD02MjIyMCxkZWJ1Zz1GYWxzZSkK

ага. раз раз разработка

Та мэссага уже не пройдёт, наверное, так что... Запилю тут клиент на Hecl, когда завал рассосётся.

переименовываешь .outmsg в .out и снова запускаешь send.

я сначала посмотрю, что там сломалось...

на 3 питоне работает?

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

формат есть - либо друг с друга пулят, либо друг другу пушат. либо комбинируют.

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

а merge это просто добавление диффа или там какая-то сортировка происходит?
btw, пулл вытягивает всю эху целиком или все-таки инкрементально?

btw, offtop - этот кодстайл меня убивает. я многое могу простить, но не среднюю длину переменной в три буквы.

> btw, offtop - этот кодстайл меня убивает. я многое могу простить, но не среднюю длину переменной в три буквы.

я не программист, и пишу в mcedit.

фишка в том, что в gnome я ВООБЩЕ не вижу, что пишу, половина текста просто невидима :) а вне mc, что-то запускать - лень, идея уже пройдёт, пока буду с лишним возиться :) поэтому - чем проще, тем проще :)

у отдельной эхи нет ничего, что можно было бы назвать "мастер-веткой"?

> у отдельной эхи нет ничего, что можно было бы назвать "мастер-веткой"?

чего нет у отдельной эхи?

это я по аналогии с гитом.
ладно, проехали, это я глупость сказал.

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

длинная эха - это сколько? не думаю, что даже 100 тыс сообщений - это проблема

и я не думаю, что будут эхи по 100 тыс сообщений. большие эхи надо делить, или тематикой, или номером (делить на месяцы, на дни, на индексы, чтобы оставлять в эхах только актуальную информацию, а не полное собрание сочинений - для этого ОБЯЗАТЕЛЬНЫЕ номера и нужны.

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

requests умеет оба.

надо будет разобраться, и прикрутить к клиентам

пойду багу повешу

>большие эхи надо делить
как их предполагается делить "на лету"? И на ком будет за это отвечать - тоссер?

> мне интересно было сделать готовую реализацию, чтобы реальные проблемы испытывать практически
на мой взгляд, довольно спорно. Некоторые проблемы могут проявиться только на больших объемах данных.

> как их предполагается делить "на лету"? И на ком будет за это отвечать - тоссер?

юзеры. пишут, пишут, потом бах - а пойдёмте все в эху "новый префикс"

а старую куда-нибудь на заморозку, технически или юридически.

ты сейчас можешь создать эху ii.dev.2015, просто написав в неё. впоследствии такие вольности будут только у нодов.

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

ну, после спам-атаки нормально было, куча эх с 3500 сообщений. не вижу целесообразности плодить такие эхи - эхи "болталки", которые оканчиваются на im.ЧИСЛО можно вообще хоть каждый день менять. а в эхах обсуждалках - много писем не наберётся, особенно, если их разделять ещё и тематически.

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

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

> то, что я тут собрал, мне нравится
мне нравится общая идея, но не очень нравится реализация.
и вот как раз в тему - какой ты видишь модель распространения изменений(новых сообщений)? я не был в фидо, так что могу не знать чего-то, что тебе кажется очевидным и общеизвестным.
так вот, я вижу навскидку два основных варианта, назовем их "каскад" и "меш".
"каскад" - организованный вариант: для каждой эхи есть группа нод N1, N2, ..., NK, которые можно назвать корневыми. ноды второго уровня, например, N11 и N21, которые знают, что эту эху нужно и пуллить, и пушить в/из N1 и N2 соответственно. ноды третьего уровня делают аналогичное с нодами второго уровня, etc.
то есть, для каждой эхи нода, кроме корневой, знает, куда пушить и откуда пуллить новые сообщения, а корневые ноды объединены в пуш- или пулл-кольцо. в этом случае достаточно легко минимизировать траффик внутри сети.

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

> постфикс, ты хотел сказать.

такого слова я даже не знал, знал преффикс, суффикс, корень и окончание :) значит, постфикс.

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

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

а у тех, кто вне "бонных" эх - могут быть вообще свои порядки :)

> мне нравится общая идея, но не очень нравится реализация.

мне не совсем нравится, как оно работает, но мне нравится, что оно работает, и мне нравится, что оно очень простое. хотя всегда хочется ещё проще :)

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

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

у меня в своё время было вообще два аплинка.

> так вот, я вижу навскидку два основных варианта, назовем их "каскад" и "меш".

прочёл, но не совсем понял.

Этот анекдот будет понятен только тем, кто помнит фидо и рекламу 90-х, но я его всё-таки расскажу:

Зима. Снежная пустыня. Около проруби сидит бородатый мужик с надписью на тулупе "ФИДО - рулез" и напряженно думает.
Неожиданно снег взлетает комьями и из-подо льда высовывается страусиная голова:
- Хаба-хаба!
Мужик медленно поворачивает голову и произносит:
- Ну вот, так уж сразу тебе и хаба?


У моей сети точно всё просто. Каждый нод договаривается со мной, как, каким образом, как часто и по каким эхам ему обмениваться. И мы обмениваемся.

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

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


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

> Сервер чего ответит 201 - я зафигачил твою месагу в новую конфу? и в заголовке Location новый путь?

Можно, но не особо нужно. особенно, если придётся учитывать все txt-клиенты и прочее. зачем переусложнять - в стандартной реализации таких переусложнений не предусмотрено.

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

Отчего переусложнение? Это просто для тех клиентов которые это поддерживают.
Все остальные клиенты прожую статус 2xx и все ок.

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

> Отчего переусложнение? Это просто для тех клиентов которые это поддерживают.

переусложнение стандартной реализации

у меня вопрос - КТО будет это передавать? у нас есть только сообщения и эхи, данные могут передаваться бандлами, пуллами, пушами и вообще любыми способами. непонятно, на каком именно участке нужно создавать. просто помечать какое-то сообщение подобным тэгом?

> Сейчас ты перенаправляешь вообще гиперссылками, это вообще ни в какие ворота.

ii: - это будет стандартный указатель на сообщения или эхи :) ii://im.2014
в принципе, для клиента это может быть уже достаточно, чтобы организовывать подписку по клику

> ii: - это будет стандартный указатель на сообщения или эхи :)
Ок. Стандарты развиваются прямо сейчас))

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

ii: был задуман изначально, потому что это самый логичный способ идентифицировать что-то, не привязывая к ноде :)

вставляй, что хочешь - это же текст :) и разбирай своим клиентом, как твоей душеньке угодно :)

при ответе через что?

http-клиент, да и через аватары на сайте.

какой msgid? где берётся, куда?

вот твоё сообщение:
msgid: tY3YMv3OViOfMXZANa5k
repto: KXMyq7O5AqNYRRwOdThA

что неправильно?

вот я сейчас отвечаю, у меня будет repto: tY3YMv3OViOfMXZANa5k а какой id, я пока не знаю.

впрочем, это очевидный оверкилл. хотя очень интересно, очень.

msgid: ii://tY3YMv3OViOfMXZANa5k
repto: ii://KXMyq7O5AqNYRRwOdThA

моё

msgid: ii://TAL3tHASZ9hWAavrgAmb
repto: ii://tY3YMv3OViOfMXZANa5k

у нас пока нет таких проблем ;) если обмениваться гигабайтами - тогда вообще многое менять придётся. а для нашего случая - обмен бандлами, которые генерируются через /z/get - хватает с огромным избытком :)

нам нельзя никак перегружать сеть вещами, которые неочевидны и непонятны. только массовое портирование сможет спасти родину :)

Я не про msgid, а msgto. Кому сообщение. Вот ты мне сейчас ответил, а отображается "tо All".

а, это. этого пока ваще нет. :) лишнее окно просто так лепить не хочу, а чтобы аккуратно в стиль вписывалось, рядом с полем сабж - надо смотреть, как это по науке делается.

кое-где вообще пустое проставляется.

сегодня что-нибудь с этим сделаю

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

должно. но пока не подставляется

в текущем сайте и в клиенте 0.1c - уже подставляется

эээ. где у тебя 9кб гет-запроса? Оо

у нас тут сейчас всё на get-запросах - отправка сообщения это тоже такой большой get-запрос :) Кодируется в base64 и жамкается в url. 5 кб ещё пролазит, 9 - нет. Когда-нибудь будет всё по уму, а пока - чем богаты, тем и рады :)

requests, смотрю, это внешняя библиотека. надо будет смотреть, какие у неё зависимости, лицензия, размер, работает ли в haiku os :)

> у нас тут сейчас всё на get-запросах - отправка сообщения это тоже такой большой get-запрос
ой, как печально. ну пост же для этого придумали. =)

> requests, смотрю, это внешняя библиотека.
pure python, в т.ч. зависимости, apache2 license, 625kb wheel со всеми зависимостями. полагаю, что работает.

> ой, как печально. ну пост же для этого придумали. =)

пока я только фидо придумал. пост пока в клиентах не придумал :) це аппаратно-программный лимитатор длины сообщений :)

> pure python, в т.ч. зависимости, apache2 license, 625kb wheel со всеми зависимостями. полагаю, что работает.

посмотрим, покрутим.

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

Что есть серверный пуш? Во время переписывания, хотя бы на BB-- пиши комменты к коду

если к коду на питон нужны коменты - то это не код на питон :)

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

Так, ну вроде получилось сделать эху и слегка настроить под себя. Осталось понять, как клиент настроить на неё