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

Тут в процессе одной из предыдущих дискуссий я пришел к выводу что использование в stilllife server-сайд конвертера HTML в BBCode и обратно было ошибкой. Между сервером и клиентом коммуникация должна производиться только в HTML. В обе стороны.
А вот представление текста поста/комментария в том виде, в каком юзеру удобно его редактировать, и преобразование из этого вида в HTML - исключительно client-side задача. Web 2.0 у нас в конце концов, или не 2.0?

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

Конечно, для того, чтобы этот код сделать удобным для использования в stilllife его придется слегка причесать.
Но вообще решение, похоже, надо внедрять. Заодно удастся избавиться от самого нестандартного и подозрительного с точки зрения безопасности перлового модуля, на данный момент используемого в stilllife - HTML::BBReverse.

Правда, как показала практика, оно умеет преобразовывать только в одну сторону. Кнопка back to html работает исключительно путем восстановления прикопанного HTML-текста.

Смотрю я на ЖЖ-посты с несколькими катами (<lj-cut> которые) и думаю: А может сделать в stilllife фичу, которая будет открывать кат без перезагрузки страницы, причем только один...

Интересно, сколько CPU и памяти потребуется сайту на DJANGO или Ruby on Rails для получения вот таких результатов:
( бенчмарка )

Гонялось это ab через loopback интерфей (где ж я вам 200Мбит/с канал в интернет возьму.

( на вот таком процессоре )

Параллельно крутилось еще много чего, начиная с X-ов и mldonkey. На протяжении всего теста load average выше полутора не поднимался.

Запрашиваемая страничка - список последних 50 сообщений из форума в 200 сообщений. ВПрочем, если бы там было 200000 сообщений, на скорость отдачи данной странички это б не повлияло.

Upd Поставил siege. Запустил вот так:

siege -i -b -t1M -f urls.txt -c 25

Где urls.txt сформирован комадной
find stilllife -name "*.html" ! -path "*/template/*" |sed s!^!http://vitus.wagner.pp.ru/! > urls.txt
Получилось ( Вот что )

Тут Алексей Печников замучал меня вопросами, почему для StillLife выбрана именно такая архитектура.

Поэтому я решил признаться в своем тайном замысле. Основная цель - убить web-кодера, как профессию.

Первым пристрелочным выстрелом в эту сторону был Communiware. Это был очевидный перелет. Концепция "информационного супа" предложенная для Коммунивера Андреем Акопянцем настолько велика и могуча, что освоить её в совершенстве могут только отдельные гении вроде ailev. Ну и ресурсов тоже кушает будь здоров.

Это не то, что нужно отдельному юзеру.

Поэтому StillLife в значительной мере Communware наоборот. Если в Communiware в базе хранились не только данные, но и программы их представления (шаблоны), то в StillLife базы данных нет вообще, если не считать пары DBM-ок, используемых для аутентификации пользователей.

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

В общем, классическая попытка взять цель в вилку.

Понятно, что получится недолет. Даже сейчас видны целые классы сайтов, реализация которых на базе концепции StillLife принципиально невозможна, например Internet-магазины. Web-форум - это предел интерактивности, которого можно добиться на базе такой концепции. Именно поэтому разработка StillLife начата именно с форумного движка. Дальнейшее - блоги и средства управления контентом традиционного сайта - будет проще.

Основное, что лежит в основе - антитеза концепции, выдвинутой ailev лет 6-7 назад "Сайт - это программа".
Как раз эта концепция, которая в общем-то в то время носилась в воздухе, приводит к тому, что вокруг WWW кормится армия криворуких кодеров. Раз сайт это программа (при этом каждый сайт - отдельная, уникальная программа), каждому сайту нужен программист. Хороших программистов на все сайты не напасешься, значит большая часть сайтов, в том числе и интересных содержательно, будут написано плохими программистами, а следовательно будут плохими, неудобными для пользователя программами.

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

Примерно в этом направлении сейчас двигаются Google, SixApart и другие подобные крупные сервисы.
Но они - злобные проприетарщики. Хотя сейчас очевидно, что создать хорошее web-приложение без использование OpenSource технологий практически невозможно, они ухитрились обойти GPL посредством исполнения программ только у себя на сайте. Раз пользователь не получает исполняемой копии программы, он не вправе требовать и доступа к исходным текстам, даже если 90% кода - GPL.

Кроме того, решения применяемые LJ, Google и другими крупными сервисныи компаниями в WWW требуют соответствующей аппаратной базы. Именно этим объясняется незначительный успех клонов ЖЖ, базирующихся на его коде. Вербицкий может взять исходники ЖЖ, которые Фитцпатрик честно открыл, но у него нету и не может быть денег для создания датацентра, аналогичного калифорнийскому датацентру ЖЖ. Поэтому Vendor Lock In в классическом виде.

Для полноценной реализации концепции "сайт - это документ", требуется программа обработки этого документа, способная выполняться на любом, доступном пользователю компьютере - будь то shared hosting, будь то домашний компьютер с широкополосным подключением к интернету. Лучше конечно, иметь несколько разных программ, адаптированных к разным средам выполнения, но работающих с одинаковым форматом документа. Именно работающих с одинаковым форматом документа. Поэтому столь распространенные нынче в веб-строительстве РСУБД не годятся. Можно создать схему БД, которая будет работать в mySQL, PostgreSQL и Oracle, но с перетаскиванием её будут некоторые проблемы - потребуются специальные срества импорта/экспорта. Да и работать она будет неэффективно, так как она будет вынуждена на каждом сервере не использовать именно те возможности, которыми он наиболее силён - из-за отсутствия этих возможностей в других серверах, совместимость с которыми поддерживается.

Я все-таки его написал. В смысле, web-форум, на статических html. Смотреть можно на http://vitus.wagner.pp.ru/stilllife.
Комментировать там же. OpenId там работает. Я не уверен в кросс-браузерной совместимости JS-кода, который открывает прямо на странице форму комментария. Если он у вас не сработает, то кнопка "Высказаться" из списка тем работает без клиент-сайд скрипта.

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

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

В соответствии с принципом release often, release early, движок выкатывается на всеобщее обозрение в незаконченном виде.
Из доступной простым пользователям функциональости не работают пока операции удаления и редактирования сообщения. Ну и всякие мелкие огрехи могут быть. В процессе доводки и отладки возможны internal server error при выполнении вообще всех операций. Но обычно такое состояние длится не более нескольких минут.

Вообще задача оказалась существенно сложнее, чем я думал. Пришлось фактически изобретать свой собственнфый framework. Пока что server-side код - около 2000 строк, не считая стандартных модулей с CPAN.