Журнал Витуса

Извел, наконец, неработоспособную ikiwiki на wiki.wagner.pp.ru. Теперь там осталась только статическая первая страница, которая послает в разные места, куда конвертирован тот же контент.

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

Теперь, бы, правда, надо эти две вики отдизайнить. В галактическую можно тупо скопировать дизайн со spacians.net. (да и вообще перекинуть этот репозиторий на этот домен).

А вот для Ясмины нужно какой-нибудь красивый CSS нарисовать.

Ежели кому нужен скрипт для конвертирования ikiwiki в fossil wiki, могу выложить. Он у меня, правда, плагинов поддерживает раз-два и обчелся. Только линки на википедию и картинки.

Внимательное изучение ситуации с NNTP-софтом показало, что трудоёмкость задачи реализации оффлайнового web-а в виде "мультимедийного usenet" несколько выше, чем мне казалось. Software rot о котором предупреждал в одной из первых дискуссий на эту тему qkowlew в этой области зашел довольно далеко, и мне не удалось, например, найти ни одного современного ньюсридера который бы поддерживал url схему news: (как сейчас помню - в Netscape 2.0 же работало).

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

Самое простое решение, которое приходит в голову, это большой статический web-сайт, хранящийся в распределенной VCS, например GIT и оснащенный продвинутой browser-based системой управления контентом.

Соответственно, живет этот вебсайт у каждого на localhost, синхронизация выполняется посредством git pull (а то и git push, но pull делается по тому же http и не требует авторизации).

Системы управления контентом, работающие с VCS в качестве бэкэнда существуют. Например. ikiwiki, на которой сейчас работает wiki.wagner.pp.ru. ikiwiki в принцпие поддерживает и агрегацию RSS-фидов и ведение блогов с комментариями. А в MoinMoin есть уже готовый механизм синхронизации wiki

Старые читатели моего журнала помнят, что год назад я пробовал перенести свой блог из ЖЖ на ikiwiki как раз с git-овским бэкэндом. Уже через три месяца постинг комментария стал занимать десяток секунд. Скорее всего это проблемы ikiwiki и могут быть довольно легко исправлены. Но всё же для оффлайнового веба нужно гораздо больше контента, чем один блог за три месяца.

Кроме того, у git существует стандартная схема генерации патчей. Которая позволяет использовать для синхронизации перенос данных на пассивных устройствах (флэшках). В рамках идеи offline web ее можно рассматривать как замену uucp-шных бэтчей в Network News.

Какие проблемы возникают у такой схемы:

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

2. Контроль целостности сообщений. В основе Network News лежит тот же формат сообщений, что и в электронной почте. Для него предусмотрены разные форматы электронной подписи. Поэтому читая подписанное сообщение мы можем быть уверены, что написано там ровно то, что имел в виду владелец соответствующего ключа. VCS предназначены для того, чтобы файлы редактировались. Да, есть история. Да, в git-е есть подпись коммитов. Но организовать подпись каждого комментария на форуме - несколько сложнее, чем организовать подпись каждого письма в ньюсридере.

3. Защита от спама. Средства защиты от спама тоже в основном развивались вокруг RFC 2822 и 5322. В ньюссерверах предусмотрено достаточно простое написание фильтров на входящий транзитный траффик (нам еще долго предстоит обсуждать какие именно должны быть критерии фильтрации транзитного траффика, я думаю что, если все пойдет по плану, копья по этому поводу будут скрещиваться еще долго после того, как сеть начнет работать. Тогда-то мы сможем обсуждать это не голословно а со статистикой в руках). В VCS этого нет. Как максимум - втаскивание чужого репозитория в отдельную ветку и ручной merge.

Обнаружилось что в ikiwiki возникает какой-то deadlock. Причем, видимо, только с использованием git в качестве бэкэнда, а то бы может давно заметили. Сейчас вот грохнул процесс git push origin (origin и рабочая копия - в одной файловой системе) и в результате смог завершиться десяток процессов и запоститься три комментария.

Но вообще с блокировками они там явно что-то перемудрили. Уж во всяком случае окно комментирования должно на порядок быстрее открываться при данной мощности машины. Причем профайлер ничего интересного не показывает.

1. Пока я его не закрываю. Прежде чем можно будет съехать на свой собственный blog, там нужно ещё много чего доделать. Поэтому содержательные посты пока будут тут.

2. Правда, когда доделаю, кроспосстов в ЖЖ/DW делать не буду. Попрошу кого-нибудь с платным аккаунтом заимпортировать RSS или atom feed, и пусть все подписываются на него.

3. И вообще, никто не хочет помочь мне с дизайном? (помочь - это патчи к local.css, а не советы)

Upd. В ЖЖ меня уже заимпортировали vitus_wagner_rs. Можно подпиываться, хотя и пока бессмысленно.

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

1. На мой взгляд ikiwiki обладает главным свойством, требуемым для веб-приложений на домашней машине - не занимает ресурсов, когда не используется.
2. Второй - то что оно устойчиво к кратковременным всплескам посещаемости, связанным с публикацией ссылок на посещаемых ресурсах. Потому что для чтения это - статика.
3. Обладает уже готовой возможностью пускать пользователей по их аккаунтам во всяких прочих системах ЖЖ, Гугль, FB etc. Это очень полезно для маленького, но публичного сайта. Чтобы не заставлять всех желающих регистроваться на yet another сайте.
4. Работает с произвольными системами версионирования.
5. Хорошая поддержка в Debian.
6. Как это ни странно для современного OSS проекта, в команде есть кто-то кто имеет представление об информационной безопасности.

Недостатки у ikiwiki тоже есть.

1. Отсутствие внятной introductory documentation. (восполнить этот недостаток отчасти призван этот пост)
2. Я пока так и не понял как кастомизировать внешний вид сайта. Для сайта вида "личная записная книжка" это и не важно.
3. Внятного руководства "что делать, если что-то не работает" тоже нет.

( Поехали )

Решил тут опять (после 5 или 6-летнего перерыва) завести собственную Wiki.
С тех пор, правда, много байтов в memory leaks утекло, поэтому выбор движка пришлось осуществлять заново.

Требования к движку у меня были следующие

1. Чтобы был в дистрибутиве.
2. Чтобы не php
3. Чтобы не требовал никаких долгоживущих процессов. Если никто с wiki не работает, то оно ресурсов и не кушает, Поэтому чистый CGI.
4. Чтобы умел пускать по OpenID. А то заставлять всех знакомых по DW и LJ регистрироваться еще раз - это как-то жестоко.

В прошлый раз у меня был TWiki. Тогда он не прокатывал по 4-му пункту, но с тех пор к нему OpenID плагин даже написали. Правда, из дистрибутива его за патологическую несекьюрность выпилили. Пришлось искать что-то другое. Исследую сейчас MoinMoin.

Сайт в индийском национальном домене, конечно. Это как бы намекает. Но вроде все фамилии в ченджлоге нормальные, немецкие, польские и прочие европейские.

Python. С точки зрения возможностей движка wiki как wiki. Поддерживает WYSIWYG через FCKEditor, интегрируется с Xapian для поиска. В отличие от многих известных мне движков, прекрасно понимает CamelCase с русскими буквами. Хотя CamelCase mustdie и надо пользоваться [[двойными квадратными скобками]] которые оно тоже умеет.

Работу с аттачментами пока не исследовал внимательно.

Очень развитая система плагинов аутентификации.

Правда, как работает OpenID плагин мне не понравилось. При первой регистрации с OpenID предлагает ввести имя. Вместо того, чтобы просто тупо прописать в качестве имени URL. Что несколько проще и понятней для юзера, чем
многоэтажный OpenID SignIn в DW, но все же не comme il faut.

На мой взгляд, любые действия, которые требуют для комментирования с внешней аутентифиацией какого-то дополнительного ввода - это плохо. Даже ввод E-Mail как в DW. Хотя E-Mail имеет собственую ценность - на него комменты слать можно. А OpenID-провайдеры его не отдают.

Зато позволяет привязать к wiki-аккаунту несколько OpenID-ов. Какую модель использвания OpenID имели при этом в виду разработчики, я совсем не понимаю. Примерно то же самое, кстати в diary.ru сделано. Там ты обязан зарегистрироваться, но зато потом можешь привязать к своему аккаунту OpenID и аутентифицироваться по нему.
Зачем тогда OpenID? Если информация о тебе все равно хранится на этом сайте, то можно и пароль вводить.


На мой взгляд, OpenID нужен для того, чтобы минимизировать (а лучше совсем ликвидировать) необходимость регистрироваться на сайте.

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