<h2>Kritika</h2>

<p>Mongrel2 idėja yra šiek tiek kontroversiška, tačiau ji turi potencialo. Čia pateikta šiek tiek kritikos pasiūlytam dizainui ir aš laukiu jos daugiau:</p>

<ul><li><em>sqlite naudojimas konfigūraciniams failams tarsi darbas su windows registru.</em> Sprendimas naudoti sqlite kaip konfigūracinių failų saugyklą kilo dėl to, kad jūs galėtumete naudoti bet kurią programavimo kalbą vientisam serverio konfigūravimui, automatizuoti konfigūracijas ir tiesiogiai suprasti jas. Jokiu būdu aš neleisiu, kad tai taptų windows registru.
</li><li><em>Konfigūraciniai failai yra geriau.</em> Pati idėja yra sukurti DSL keliomis programavimo kalbomis konfigūracinių failų nauodjimui ir, galbūt, vertiklį iš Nginx ar Apache. Kadangi sqlite yra standartizuota talpykla ir reliacinis modelis yra lengvai susietas, yra įmanoma sukurti daugiakalbę konfigūraciją.
</li><li><em>Jis turėtų būti paremtas įvykiais, o ne naudoti korutinas ar gijas.</em> Jis yra paremtas įvykiais ta prasme, kad jis naudojasi kqueue/epoll/poll/select, tačiau naudoja korutinas tam, kad pašalintų įvykiais paremtų sistemų sudėtingumą.
</li><li><em>Flash čiulpia, naudokit ką nors kitą.</em> JSSockets veikia ir jie yra patikimi. Kai bent 2 naršyklės palaikys WebSockets - aš taip pat juos pridėsiu. Mongrel2 veikia su ilgu tikrinimu (long polling), tačiau tai nieko įspūdingo, tiesiog taip veikia Mongrel2. Tai įspūdinga tik tuose web serveriuose, kurie čiulpia.
</li><li><em>Jis privalo pateikinėti bylas.</em> Jis pateikinės bylas, ir kadangi tai pirmasis pasididžiavimo matmuo, kurį naudoja visi - jis tai darys labai sparčiai. Tiesiog Mongrel2 teiks palankumą <b>kalboms agnostiškoms</b> aplikacijoms negu paprastų bylų pateikimui.
</li><li><em>Žmonės nekenčia SQL</em> ir jie nenorės to naudoti Mongrel2 konfigūravimui. Tikėkimės jie neprivalės naudoti SQL nebent bus nusiteikę padaryti ką nors pažangesnio. Vietoje to žmonės naudos terminalinę prieigą, kuri tai atliks už juos.
</li><li><em>SQLite3 bus labai lėta</em> ir nesiplės. Ne, SQLite3 labai tiks, aš nekrausiu visko iš sqlite bylos per kiekvieną užklausą. Tai kvaila.
</li><li><em>SQLite3 netinka peržiūrai su Diff/Git</em> tad aš negaliu jos naudoti. Taip, sqlite3 byla netinka, tačiau planas yra naudoti migracijas konfigūracijos pakeitimų atkartojimui, taip pat, kaip jūs tai darote su Rails, Django ar bet kokia kita modernia web aplikacija. Tos migracijos tikrai tinka peržiūrai su Diff/Git.
</li><li><em>SQLite3 nėra tinkama staigiems pakeitimams</em> tad aš užstrigsiu avarinėje situacijoje. Tai SQL duomenų bazė, viskas yra pagrįsta pakeitimais ir jūs nenaudosite SQL tiesiogiai, tad tai tiesiog yra neteisinga. Jūs ne tik galėsite viską greitai pakeisti, tačiau taip pat vienu žingsniu galėsite atkartoti pakeitimus visuose savo serveriuose, atstatyti juos atgal kaip ir atlikti begale kitų naudingų veiksmų.
</li><li><em>Programuotojams bus blogai</em> kadangi daug daugiau yra pabrėžiamos operacijoms. Ne, daug dėmesio yra skiriama abejoms pusėms, tiesiog operacijų dalis dėmesį gauna pirmoji. Be abejo jūs būtinai gausite "5 minučių pradžią" ir galėsite paleisti savo aplikaciją taip pat stagiai kaip ir visi kiti konkurentai.
</li><li><em>SQLite nepalaiko hierarchinių konfigūracinių failų, kaip Nginx.</em> Visų pirma, žmonės turi omenyje, kad SQL apskritai turi problemą talpinant medžius į lenteles, kas yra tiesa, jei struktūrą yra pasikartojanti ir pasiveldėja pati iš savęs, paavyzdžiui kaip komentarų gija. Nginx konfigūracijos <em>nėra</em> hierarchinės šia prasme. Jūs negalite sukišti serverio aprašymų į juos pačius, nei vieną location bloką į kitą, nei sukurti dar ką nors panašaus į tikrą hierarchiją. Tiesa ta, kad Nginx konfigūracija yra tam tikru būdu apribota lentelių ir ryšių forma, kur serveriai turi daug location blokų, o location blokai turi daug proxy stočių ir t.t. SQLite3 gali tai puikiai palaikyti taip pat kaip ir papildomus ryšius, kurių nepalaiko konfigūraciniai failai.
</li><li><em>Versijavimo problemos su Ubuntu ar kita Debian sistema.</em> "Diegiant fossil jums reikia tam tikros SQLite3 versijos, kitu atveju ji neveiks, kas reiškia, kad Mongrel2 laukia tokios pačios problemos." Kaip ir visą programinę įrangą, jeigu norite naudoti pažengusią technologiją - privalote ją visada atnaujinti. Jeigu mes visi lauktumėme stabilaus Debian sistemos išleidimo, mes vis dar naudotumėme Apache1 ir Linux 2.0. Vietoje to - mes kuriame modernią programinę įrgangą, kuri reikalauja modernios technologijos, ir be abejo, tai reiškia, kad jeigu jūs bijote atnaujinti savo programinę įrangą - jūs nesinaudosite Mongrel2. Be kita ko, tai taikoma SQLite3 naudojimui fossil programoje, ne Mongrel2. Fossil reikalavimai sistemai yra žymiai labiau pažengę negu Mongrel, kadangi tai yra išbaigta versijavimo sistema, kuri saugo išskirstytą failų sistemą SQL formatu. <b>Mes tesaugome adresus bei portų numerius.</b> Galiausiai, šie apribojimai tinka bet kurioms bibliotekoms. Nesvarbu ką nuspresite naudoti, kai kurios Linux distribucijos neturės jums tinkamos versijos ir vienintelis sprendimas bus parašyti viska nuo pradžios. Asmeniškai, aš neturiu laiko rašyti viską nuo pradžios, tad aš ketinu naudoti bibliotekas. Diskusijos pabaiga.</li></ul>
