Простейший клиент для блога можно сделать локально на html+js. А если я работаю с «однофайловым вики» (gtd, notes, планирование), то такой клиент можно туда же и встроить.
Отсюда вопрос — а почему в современных блог-клиентах нет вики? Нет рабочей среды?
Или, если ставить вопрос чуть иначе, почему клиенты не делаются как вики?

ps. Я, кстати, второй месяц обдумываю идею, как можно реализовать админку в виде вики (как вариант, совместить в админке вики и классический «backoffice»). Но пока что в голове не укладывается.

Собственно вот: «Отдельно стоящие блоги: пути развития»

В деле борьбы с нежелательными комментариями до каких только извращений не доходят… а вот использовать коды активации никто не пробовал?
Речь, собственно идет о стандартном методе, который часто применяется при регистрации в различных сервисах. После регистрации (методом заполнения регистрационной формы на сайте) реципиенту высылается код активации, при переходе на который аккаунт считается подтвержденным. Если активации не произошло, через какое-то время такая регистрация выкидывается в мусор.
Так вот, можно и с комментариями делать точно так же. «Запостил комментарий? А теперь подтверди его.» Т.е. после того как посетитель отправил комментарий, показываем код активации этого комментария (или отправляем его на указанный майл) и требуем активировать. Нет активации за N времени — автоматически спихивается в мусор.

Но самым убойным вариантом защиты от ненужных комментариев будет, наверное, полиморфизм. Точнее — мутация защиты. Если, к примеру, на одинаковых движках защита будет отличаться, то массовое окучивание будет уже затруднительно. А если защита начнет мутировать не просто на уровне движка, а на уровне отдельных записей…

Я вот прикинул, кто мог бы стать первопроходцем в деле прикручивания личной социальной сети к блогу. По всем параметрам получается, лучшая кандидатура — Дима Смирнов.
У него и подопытные кролики зарегистрированные пользователи есть, и думает/проектирует хорошо…

С другой стороны, может, не торопить события — и пусть все идет своим чередом?

Есть такая хорошая штука — функционально-стоимостный анализ (ФСА). Позволяет оптимизировать различные штуковины. Весьма эффективно оптимизировать.

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

Золотая середина? Ну, она как бы есть, но. Этот вариант оказывается самым худшим вариантом — мало того, что функциональность куцая, так еще и тормозит. [самое интересное, что такой вариант все-таки пользуется популярностью, 80% движков — это попытка найти золотую середину]

И вот тут мы возвращается к ФСА. Идея вот в чем: берем универсальный движок, настраиваем/наращиваем функциональность до нужной — а потом оптимизируем его в специализированный (быстрый, монолитный). Правда, при попытке добавить (или изменить) функциональность придется оптимизировать заново… но не каждый же день это потребуется.

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

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

Года три все было лень это выложить. Но вот пришел Илья Бирман и спровоцировал ;)

Имитация иерархических keywords — это когда иерархических keywords на самом деле нет, но их эффекты работают. Объяснять не хочется, поэтому просто покажу на примере.

Допустим, у нас есть вот такая структура:

~* — «все остальное»

На «линейную» схему она отображается просто:
lit.azimov
lit.asprin
lit
lit.asprin.myth

Выборка:
lit.* — вся структура lit, включая ветки azimov и asprin
lit.asprin.* — ветка asprin, включая asprin.myth

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

А есть ли какой WYSIWYG инструмент, чтобы в нем на экране показывался обычный текст, а на разные кусочки (слова, абзацы, разделы) в этом тексте навешивались бы «технологические пометки» (например, коды. Или переводы. Или ссылка на словарное значение, причем словарь -- другая программа. Или и то, и другое, и третье вместе). [ >>> ]

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

Во-первых, линейная стратегия чтения книги уступает место фрактальной стратегии чтения гипертекста. Кстати, если верить популяризатору концепции интеллект-карт и теории радиантного мышления Тони Бьюзену, именно нелинейная стратегия усвоения текста наиболее близка процессам, происходящим в мозгу. Ведь нейронные сети тоже скоре не линейные образования, а фрактальная „паутина“. Это даже на развитии приемов художественной литературы отразилось. Про единство места и действия давно уже мало кто вспоминает. Напротив, вводится множество побочных сюжетных линий, которые возникают и обрываются в самых неожиданных местах. Несоблюдение хронологии и причинно-следственных связей. Художественное произведение превращается в пазл, который собирается в конце, если читатель запомнил достаточно ключевых моментов, разумеется [ >>> ]

 — … и в итоге мы приходим к выводу «Чем дальше в лес, тем больше потребность в движке, основанном на фрактальных принципах организации информации»
 — Это как? – удивилась Лани, хотя была готова к такому развитию мыслей со стороны Никс.
 — Ты о фрактальности? Известно, что записи сами по себе в воздухе не висят, а интегрируются в общую картину, часто встраиваясь в структурную связку с уже существующими записями. Так вот, самый эффективный и красивый способ раскрывать эту структурную связанность – это фрактальное представление.
 — Ага, — согласилась Лани. – Фракталы – они красивые… такие лапочки…
Никс улыбнулась.
 — Ну, а так как фракталы можно раскрывать различными способами, то это позволит…
 — … представлять записи и их структурные связи тоже различными методами. Правильно?
 — Правильно, — согласилась Никс. – Напоминает нелинейный view point, когда при его смещении структура наблюдаемой системы адаптивно изменяется.
Никс сделала глоток холодного чая и продолжила:
 — Но нам, к сожалению, это не светит.
 — Это почему? – запротестовала Лани. – Как только у меня потекли слюнки, так ты тут же убираешь этот замечательный тортик!
 — Ну, во-первых, тогда надо писать движок «с нуля»… а на это мы сейчас не можем пойтить. Во-вторых, математика. На разработку математики у нас сейчас нет ресурсов. Увы…
 — Ууу!…
 — Без паники! Просто нам придется идти двумя путями одновременно. На первом мы займемся research нового движка, его математики и алгоритмов. На втором – продолжим совершенствовать существующий движок. Если повезет, то и попробуем на старом движке некоторые элементы нового.
 — Ох, и замучаемся мы… Кстати, напомни, — попросила Лани, — до чего мы договорились и допланировались по модернизации движка.
 — Основная концепция – это концепция мозаики. Если записи — это кусочки мозаики, то их надо объединять. Концепция базируется на трех китах
a) Классификация. Мы сейчас используем keywords. Это хорошо и удобно, но записей по некоторым ключевым словам получается так много, что это начинает напоминать свалку. Можно, конечно, раздробить их… но это временное (и не всегда логичное и удобное) решение. Поэтому нужна еще одна классификация – перпендикулярная существующей. Которой у нас пока нет… в смысле – в готовом виде. Надо думать, экспериментировать
b) Метаинформация. Не всегда нужна, но часто очень поможет. Не знаю, нужна ли она читателям, но нам-то точно нужна – и для поиска, и для уточнений, и для shadow info/notes.
c) Связи. Если у записей есть связи с другими записями, то с ними надо эффективно работать. И для этого нам не помешает «ежик связей». Визуально его, наверное, можно представить как клубок ниток, из которого торчат спицы связей.
 — А связи какие? – на всякий случай решила уточнить Лани.
 — Ну, пока такие: threads, groups («see also») и nodes. Возможно, что появятся и другие. Напоминаю, что группы, в отличие от threads, не линейная связь, а агрегативная.
 — Да, я помню. Мы еще говорили о «втором слое»…
 — О контекстных вставках второго слоя? Ага, говорили. Но пока толком не определились, как это должно работать. Так что их мы оставляем на сладкое. Или пока Джи не осенит хорошая идея по этому поводу.
 — Отлично! Будем покусывать Джи — чтобы ее быстрее осенило…