ребят.

не могу понять. вот например если сравнить с двачами.

в двачах есть тематичные разделы: /a , /aa , /b , /k, /m , /ma , /vn , ... и так далее..

например каждый тематичный раздел двачей -- можно сравнить с "эхой" (верно?)..

но разые двачи не являются распределёнными -- то есть они не синхронизируются между собой. будем считать что это основное отличие от ii .

но в двачах -- я создаю первоначальное сообщение, и затем в рамках него -- идёт общение.

то есть двухуровневая организация:

тематический_раздел -> стартовое_сообщение -> ответные_сообщения

а такое чувство что тут (в ii) на один уровень меньше:

тематическая_эха -> сообщения_и_ответные_сообщения

если я правильно понял -- объясните пожалуйста.. как же можно было бы (в ii) писать шокирующие новости и потом обсуждать их?

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

... :) и допустим что я проделал всё это с баночкой и *СЛУЧАЙНО* -- у меня всё-таки получился кораблик (а не говно) --- разумеется об этом сразу нужно написать в ii и обсудить это... но как? :-)

> если я правильно понял -- объясните пожалуйста.. как же можно было бы (в ii) писать шокирующие новости и потом обсуждать их?

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

> ... :) и допустим что я проделал всё это с баночкой и *СЛУЧАЙНО* -- у меня всё-таки получился кораблик (а не говно) --- разумеется об этом сразу нужно написать в ii и обсудить это... но как? :-)

эха - она же лента, имеет ТЕМАТИКУ. разумеется, если что-то интересно всем членам эхи, то это можно обсуждать прямо в эхе, никакого формализма нет.

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

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

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

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

новость про баночку-и-спички -- я поидее бы должен буду написать в эху посвящённую рукаделию? (если такая есть)

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

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

> новость про баночку-и-спички -- я поидее бы должен буду написать в эху посвящённую рукаделию? (если такая есть)

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

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

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

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

когда тематики сильно перемешиваются - эхи разделяются. когда трафика мало - объединяются. всё, как в фидо, только можно делать намного оперативнее. :)


> то есть -- получается что ii ближе к чатам чем к форумам? такой своего рода замедленный чат?

сообщение со станции spline идут иногда по рутингу часа два :) ну ооочень замедленный чат :)

> когда тематики сильно перемешиваются - эхи разделяются. когда трафика мало - объединяются. всё, как в фидо, только можно делать намного оперативнее. :)

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

все сообщения в эхе -- которые имеют одинаковую тему (игнорируя слово /^Re\:\s*/) автоматически отображались бы пользователям как дополнительный уровень иерархии?

(то есть в ней было бы: тематическая_эха -> тема_сообщения -> сообщения_касаемые_этой_темы )

это было бы сильным нарушением спецификации ii?

> все сообщения в эхе -- которые имеют одинаковую тему (игнорируя слово /^Re\:\s*/) автоматически отображались бы пользователям как дополнительный уровень иерархии?

ветки можно строить проще - по msgid и repto. в версии 0.1 была подобная функциональность, но она была 1. кривоватой, 2. не прижилась.

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

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

кстати, в отличие от настоящих фидошников, которые сабжи не меняют, мы иногда меняем :)

в общем, на текущий момент невостребовано :)

> все сообщения в эхе -- которые имеют одинаковую тему (игнорируя слово /^Re\:\s*/) автоматически отображались бы пользователям как дополнительный уровень иерархии?
> (то есть в ней было бы: тематическая_эха -> тема_сообщения -> сообщения_касаемые_этой_темы )
> это было бы сильным нарушением спецификации ii?
Нет, конечно же, нарушений никаких нет, правда для реализации придётся парсить всю базу, и, может быть, даже кэшировать её. При огромном количестве сообщений могут появиться проблемы с производительностью.

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

да, именно это я и имею ввиду!

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

> кстати, в отличие от настоящих фидошников, которые сабжи не меняют, мы иногда меняем :)

изменение темы -- это даже хорошо! изменение темы автоматически создаст новую цепочку (в описываемой мною схеме).

ведь действительно бывает такое что обсуждать начали одно а в итоге всё это привело к другому. :-)

> да, именно это я и имею ввиду!

> можно попробовать. да. не уверен что хватит моего уровня знаний для реализации.. но попытаться можно...

есть url вида /q/msgid1/msgid2, вроде бы он есть и в клиенте, и в сервере. то есть, достаточно на сообщение повесить кнопку, с подобным url - и интерфейс готов.

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

> изменение темы -- это даже хорошо! изменение темы автоматически создаст новую цепочку (в описываемой мною схеме).

а, ну по сабжу - так вообще отбирать просто... просто где-нибудь делаешь список вида

[x for x in msglist if x == u'Re: %s' % subj], вот тебе и отбор. исходное сообщение, если нужно, добавляешь сам :). ну, или если в любом месте - то [x for x in msglist if x in (u'Re: %s' % subj, subj)]

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


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

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

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

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

ну и быть может надо подумать над тем чтобы была бы возможность распределённо хранить эту базу данных (shard database architecture? то есть postgree не подойдёт? нужно mongodb?)..

^^^
|
`----------------- вообщем -- вот в этом всем -- я вижу <нечто> такое, оторое мне говорят "быть может всё это сложнее чем кажется на первый взгляд".. :-)

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

ну и храни в list() если ты не собираешься хранить 5 000 000 сообщений, это будет больше, чем достаточно.

либо вложенный list, либо dict. я dict использовал.

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

у меня на http://nz.51t.ru поиск по подстроке в заранее подогнанном тексте занимает мгновения. :) но там много чего нет, конечно, зато реализация - три строки на python. и одна - на подготовку данных при загрузке. :)

я вообще не понимаю, зачем на данных непромышленных объёмов использовать базу данных :)