Поставил e2, который, как уверяют, но 93% лучше, чем Register. Но так и не понял — в каком именно месте он на 93% лучше?
Зато, по моему субъективному мнению, e2 по многим некоторым позициям проигрывает Register. Но, из вредности, не скажу. ;)
Впрочем, еще 33 тысячи версий — и золотой ключик будет у нас в кармане.

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

А я до сих пор думаю, что keywords (особенно, в экзотических вариантах) мало полезны. Равно как и традиционные системы классификации. И большого смысла для блогописателя в них нет.
Остается жуткий, но правильный путь — придумать систему классификации самому. Для себя.
(Я все больше склоняюсь к ассоцитивно-DM-линкованной системе)

Связывать друг с другом записи — это очень хорошо, но тут другая проблема. В блоге это вряд ли будет работать, потому, что блог хочется писать, а не связи в нём настраивать. Кейворды, они тем и полезны, что позволяют мало напрягаться. А представим, что нам вместо кейвордов нужно вручную перечислять все заметки, которые мы считаем близкими по теме к данной. Ну и что, кто бы этим пользовался? [ >>> ]

• threads: не сложнее keywords, хотя возможности пока ограничены
  
• Хвост и грива: как упорядочивать записи
  
• bonus track
  

«Не хватает важного кусочка — и потерян смысл всей вообще истории, а тот, у кого кусочек на руках, не знает, что ему с ним делать.»
(Маятник Фуко)

Надо сказать, что КС¹ — это простой, но малоэффективный способ классификации. Поэтому взякие извращения (типа древовидных, спиральных, etc) обычно усложняют систему КС, но ожиданий не оправдывают (иначе говоря, сложность СК растет быстрее, чем эффективность).

Большинство СК (систем классификации) занимается тем, что раскладывают записи на кучки (по принципу «чем меньше куча — тем быстрее в ней можно откопать нужное»).
Примерно так:

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

Но обычные СК не группируют контекст и не учитывают динамику (т.е. не видят цепочек типа «поставлена задача»-"возможные пути решения" — «решена вот так»). Требуется система линковки (связывания по контексту/динамике) записей.
Иначе говоря, вместо того чтобы накладывать на систему КС дополнительные уровни, для раскладывания контента по полочкам лучше использовать «альтернативные методы» — вопрос даже не в том, чтобы аккуратно разложить записи по полочкам и кучкам, а в том, чтобы ориентироваться в контенте как рыба в воде — т.е. не только быстро найти нужную запись, но и связанные с ней контекстным вектором. Чудес не бывает, но чем больше возьмет на себя СК, тем лучше для нас.

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

Для связывания записей можно использовать:
- намеки (hints) и  ручная настройка привязки
- сотовая классификация
- ассоциативная классификация

Линковку записей проще всего делать нитями. Пользователю достаточно внести имя нити (новую или из списка), в которую попадет эта запись:

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

[-1]

В дополнение к «Связи данных» надо сказать, что многие вещи в readme не реализованы по причине того, что я чаще всего занимаюсь небольшими, но нетрадиционными вещами. А прикладные проекты мне тянуть трудно. Вы будете смеяться, но я не знаю php… хотя скрипты на нем пишу.
Идей, однако, хватает. Желающие могут прошерстить readme — по классификации записей и блогостроению я много чего писал. И еще напишу — например, о record embeding.

Поскольку R1.5.M^* позволяет корябать записи с использованием html, wiki и user-defined parser (причем, одновременно), необходимо отнять 10% от декларированных в e2 93% ;)

^* — R1.4 после небольших доработок

(… а на третий день руки дошли до «выложить запись в онлайн», поэтому see also)
Надо заметить, что в момент перехода на R1.5.M я сознательно отказался от ЧПУ и перешел на построение линков по методу «Темза, сэр!»
Дело в том, что после недолгих размышлений на тему «какая схема линков удобнее» я остановился вот на каких факторах:
1. Небольшая длина (чтобы можно было заносить линки вручную). Линки a-la Wiki все же избыточны [ >>> ]
2. Ясность в том, куда и насколько далеко можно уйти по этому линку
3. Мнемоническая нагрузка на линк

Попытка учесть все эти факторы и привела к существующим сейчас линкам. К сожалению, алгоритм формирования мнемоники получился далеким от совершенства, но «наша фирма работает над этой проблемой».

p.s. Возможность ручного ввода линков есть, но… лень.

Я вот что подумал… не буду я писать новый движок. Поскольку ничего революционного в ближайшее время не планируется, можно ограничиться вялотекущим upgrade. Писать движок «с нуля» (или кардинально переделывать) имеет смысл вот в каких случаях: «под фичу» или новую/экзотическую технологию. А вот повторять функциональность «обычного блога» (даже доводя ее до абсурда совершенства) — не вижу смысла.

Есть интересная идея — сделать клиент для блога в виде плагина для Far’а.
В плюсах: удобный и привычный интерфейс, возможность работы с блогом как с файловой системой — просмотр (F3), редактирование (F4), добавление новой записи (Shift-F4), раздела (F7), etc.
Значимых минусов пока не вижу.

Есть два варианта работы такого плагина:
а) прямое общение с блогом через RPC API блога
б) через дополнительный уровень абстракции — BFS (Blog FileSystem). Это позволит настраивать «независимый от платформы блога» клиент на RPC API любого движка.

Второй вариант, конечно, предпочтительней, хотя и сложнее в реализации.

Кто возьмется?

За два года (2003, 2004) по данным экспорта:

Всего записей: 1865
Из них активных: 1260