<h2>Критика</h2>

<p>Идея Mongrel2 слегка противоречива, но у неё есть потенциал. Вот некоторая критика по-поводу предложенного дизайна и я ожидаю ещё больше:</p>

<ul>
<li><em>Использовать sqlite в качестве конфигурационного файла &mdash; всё равно, что работать с реестром Windows.</em> Идея заключается в том, чтобы использовать sqlite в качестве хранилища для конфигурационных данных, которые легко можно настраивать, мигрировать и автоматизировать в любом языке. И я ни в коем случае не позволю ему превратиться в ещё один реестр Windows.</li>
<li><em>Конфигурационные файлы лучше.</em> Идея заключается в том, чтобы создать предметно-ориентированный язык для описания конфигураций, реализованный в наиболее популярных языках программирования. Поскольку sqlite &mdash; стандартизованное хранилище и такой язык легко отобразить в реляционную модель, то этот механизм несложно реализовать.</li>
<li><em>Сервер должен быть построен на событиях, а не корутинах или потоках.</em> Он и построен на событиях в том плане, что он использует kqueue/epoll/poll/select. Но сложность событий скрыта с помощью корутин. Получается оптимальное решение.</li>
<li><em>Флэш &mdash; отстой, используйте что-нибудь другое.</em> JSSockets работают, и работают надёжно. Когда технология WebSockets будет нормально реализована хотя бы в двух браузерах, я добавлю её полную поддержку. Mongrel2 использует механизм long polling и не испытывает с ним проблем, как некоторые отстойные веб-сервера.</li>
<li><em>Он должен уметь обслуживать статические файлы.</em> Он будет это делать, и будет делать это быстро, поскольку это самая популярная и примитивная метрика, по которой оценивается производительность серверов. Но дело в том, что Mongrel2 отдаёт предпочтение приложениям, нежели просто файлам.</li>
<li><em>Людям не нравится SQL</em> и они не захотят его использовать, чтобы конфигурировать сервер. Им и не придётся, если они не захотят сделать что-то продвинутое. Вместо этого они воспользуются утилитой, специально разработанной для этих целей.</li>
<li><em>Движок SQLite3 медленный и не масштабируемый.</em> С этим всё в порядке &mdash; я не собираюсь обращаться к базе каждый раз, когда в сервер приходит запрос. Это глупо.</li>
<li><em>SQLite3 не дружит с Diff/Git, так что я не могу его использовать.</em> Да, сам файл базы &mdash; нет. Да вам и не нужно хранить его в системе управления версиями &mdash; вместо этого вы будете хранить изменения в миграционных скриптах, наподобие тех, которые есть в Rails, Django и любой другой современной платформе. А эти файлы легко поддаются внесению в репозиторий и дальнейшему сравнению.</li>
<li><em>Файл SQLite3 тяжело изменять</em> и для меня это большая проблема. Смотрите, есть база и в неё нужно внести изменения, но для этого вы не будете использовать язык запросов непосредственно. Для этого есть специально разработанный инструмент. Так что это утверждение в корне неверно. Более того, вы не только сможете быстро вносить изменения &mdash; вы сможете делать это одновременно на всех ваших серверах, откатывать эти изменения при необходимости и выполнять кучу других полезных задач.</li>
<li><em>Mongrel2 не очень хорош для разработчиков, поскольку слишком большой упор делается на операционные нужды.</em> Нет, Mongrel2 однозначно будет хорош как для разработки, так и в качестве реально работающего сервера. Просто нужды реального сервера немножко более приоритетны. Не переживайте, как и у всех конкурентов, у нас будет свой "курс молодого бойца", который позволит вам быстро написать и запустить своё первое приложение.</li>
<li><em>SQLite не может обрабатывать иерархические структуры как NGinx.</em> Многие говорят о проблемах реляционных баз данных с хранением древовидных структур, и это правда, если эти структуры ссылаются сами на себя и имеют произвольный уровень вложенности, как, например, система комментариев. Но конфигурационные файлы NGinx не имеют ничего общего с такой структурой. Вы не можете в NGinx, например, внести определение сервера внутри другого аналогичного определения, или определение локации в другой локации, в общем, никакой такой иерархии. На самом деле, конфигурация NGinx, это некая ограниченная форма таблиц и отношений между ними, где вы можете задать сервер, а внутри него несколько локаций, а внутри локаций прокси и т.д. SQLite3 легко справляется с хранением таких отношений.</li>
<li><em>Проблемы версий в Ubuntu и других Debian-системах.</em> "Когда ставишь fossil, он требует определённой версии SQLite или отказывается работать. Это значит, что у Mongrel2 будут те же проблемы". Как в любом софте, если вы хотите пользоваться передовыми разработками и технологиями, то вам нужно периодически обновляться. Если бы мы ждали, пока Debian включит самый последний софт, мы бы до сих пор использовали Apache 1 и Linux 2.0. Мы же пишем современный софт, который использует современные технологии. И если вы безразличны к софту, который используете, то, скорее всего Mongrel2 не для вас. Кроме того, это даже в большей степени применимо к fossil, чем к Mongrel2. Fossil предъявляет большие требования, поскольку это полноценная система контроля версий, которая хранит распределённую файловую систему с помощью SQL. <b>Мы же, в основном, храним пути и номера портов.</b> В конце концов, любой выбор сводится к этому ограничению. Какую бы библиотеку вы ни решили использовать, найдётся тот или иной дистрибутив линукса, который не поддерживает нужную вам версию, и единственное решение &mdash; писать всё самому и с нуля. У меня же нет времени писать всё с нуля, поэтому я использую библиотеки. Конец дискуссии.</li>


