Портация на новый agile language

Материал из Eludia
Перейти к: навигация, поиск
Pm.gif Здесь описана идея, которая в настоящий момент не реализована в Eludia.pm. Однако, может быть, однажды... Такие случаи уже бывали.

Содержание

На протяжении семи лет разработки Eludia.pm мы не просто писали то, что хочется, используя однажды излюбленные средства, но ещё постоянно оценивали, насколько правильным оказался этот выбор, анализировали проблемы и рассматривали альтернативы на будущее.

Серверные проблемы

Публичный хостинг

Очевидной ахиллесовой пятой Eludia.pm, как и любого Web application framework'а, написанного на Perl5, является невозможность использования дешёвого массового хостинга. Это практически закрывает для нас такой рынок, как публичные сайты средней руки. В своё время мы попытались решить эту проблему, портировавшись на PHP, однако редкостное, невыносимое убожество этого языка убило практически весь комфорт, к которому привыкли пользователи Eludia. Так что мы почли за лучшее сосредоточиться на сегменте корпоративных Intranet-систем, для которых мысль о внешнем хостинге за $5 неприемлема изначально.

Корпоративный хостинг

Когда внедряешь заказное решение в большой конторе, ситуация с выделением серверных мощностей и выбором платформы бывает вполне благоприятной, однако здесь возникают свои сложности — в основном интеграционного плана. Стыковаться с чем-либо по TCP/IP при наличии подходящего драйвера, конечно, легко. Но вот если возникает необходимость использовать библиотеки, живущие только в среде JVM или CLR — что тогда? Ясное дело, Web-сервисы всех спасут, но, по совести говоря, использовать SOAP для передачи данных внутри приложения — дело распоследнее.

Более конкретная проблема: под Win32 пока не удалось обнаружить приличного Web-сервера с поддержкой Perl5. Такого, чтобы можно было с чистой душой надолго выставить под большую нагрузку. Минимальное требование: чтобы сервер приложения в целом (со всеми Perl-интерпретаторами) запускался и останавливался как Windows-сервис. Поскольку отдельно стоящего Perl'ового FastCGI-сервиса пока вроде не изобретено, остаётся вот что:

  • Apache 1.x / mod_perl 1.x — однозадачность;
  • Apache 2.x / mod_perl 2.x — необходимость самому собирать из исходников вообще всё (Apache group, увы, бинарных сборок mod_perl давно не выпускает);
  • IIS / PerlEx — зависание в памяти нитей PerlEx после остановки IIS.

Собственно, такая ситуация — отчасти проблема не с Web-серверами как таковыми, а с Perl5 в контексте Windows. Противоречие в том, что:

  • ядро NT — до того всё на ниточках, что вызова fork не предусмотрено вообще;
  • попытка use Thread (системные) в Perl 5.005 - 5.6 провалилась под тяжестью унаследованного не-thread safe кода;
  • ithreads в Perl 5.8 и выше — это по сути клонирование целых виртуальных машин и запуск отдельных процессов, что под Win32 опять-таки красиво не делается.

Экосистемы

Здесь мы подходим к ещё одному весьма грустному моменту: к принципиальной непортируемости Perl5. В самом деле, многие динамические системы программирования, более-менее сопоставимые с Perl5, успешно воплощены не только в собственных вируальных машинах, но и в рамках "экосистем" java и .Net:

java .Net
Python Jython IronPython
Ruby JRuby IronRuby
javaScript Rhino JScript.NET
PHP Quercus Phalanger


В то же время проект jPerl, похоже, успешно загнулся, а IronPerl и не думал начинаться. Есть всяческие самоделки типа sleep, однако нас интересует не "фантазия на тему", но адекватный перевод с обеспечением совместимости прикладного кода. Увы, уникальность Perl среди языков программирования (его синтаксис до сих пор не описан и, вероятно, вообще не может быть выражен в виде BNF или чего-то подобного) практически намертво привязывает его к единственной существующей реализации, писанной на C. Время от времени возникает светлая идея воспользоваться PPI или даже B и наладить генерацию байт-кода для JVM или CLR, но пороху как-то ни у кого не хватает. А в связи с тем, что лучшие умы людей доброй воли в последние лет 10 мобилизованы на вавилонскую стройку Perl6, ждать тут вообще нечего.

Клиентские проблемы

Это может показаться неправдоподобным, но первые варианты дизайна того, что сейчас называется Eludia::Presentation::Skins::Classic, верстались вообще без картинок. Причём это делалось намеренно. Целью было создание чисто текстовых Web-интерфейсов с меню, таблицами и формами в духе Norton Commander. И на определённом витке эволюции это было вполне к месту: "тонкие клиенты" тогда смотрелись именно возвратом от перегруженности Windows к аскетизму ANSI-графики, а AJAX (в смысле общедоступности XMLHttpRequest), к слову сказать, ещё не было. При таком подходе application framework естественным образом строился на базе понятия "страница" или, как это называется у нас, "тип экрана". Каждый HTTP-запрос — либо загрузка Web-страницы (целиком), либо редактирование данных, по итогам которого опять-таки приезжает новая Web-страница. Со временем наметился отход от этой парадигмы, однако лишь временами и в мелких деталях.

Теперь — не то. Нынче на повестке дня RIA, то есть, по сути своей, толстые (до ужаса) клиенты, писанные на javaScript и исполняемые в адресном пространстве браузера. Страница у приложения, собственно говоря, всего одна. В её HEAD-части стоит закачка тяжеленной js-библиотеки, а BODY более-менее сводится к onLoad. Дальше в DOMе творятся всевозможные метаморфозы, сопровождаемые спорадическими асинхронными HTTP-запросами на голые данные в формате JSON. В последние год-два появилось (или раскрутилось) сразу несколько серьёзных наборов widget'ов, которые более-менее предполагают вышеописанное устройство приложения:

Глядя на всё это, как-то не испытываешь особого энтузиазма по поводу будущего Eludia::Presentation::Skins. Была попытка подключить туда ExtJS, но тогда всё кончилось лишь осознанием мудрой фразы: " MVC is godawful for RIA". Если уж связываться с этими RIA-библиотечками, так, значит, играть по их правилам: выкидывать Presentation из ядра напрочь, а Presentation приложения писать без дураков как статический HTML/js.

Параллельно в коллективный эротический тур отправляются кое-какие наши славные интерфейсные находки и приёмы:

  • кнопка esc, связанная с серверным access log'ом;
  • двойственость режимов просмотра и ввода для форм;
  • возможно, недосозданные записи тоже.

Что делать?

Итак, мы сформулировали несколько проблем, так или иначе ограничивающих развитие Eludia.pm в его нынешнем виде. Возникает вопрос: а стоит ли вообще продолжать в том же духе? Не переучиться ни на какой-нибудь, допустим, Oracle ADF faces (желательно, на Карибах) — и оставшиеся 10-15 лет спокойно прожить на благо родимого пенсионного фонда? Постигать новое, конечно, никогда не вредно, но остаток этого текста предназначен для тех, у кого несколько иные жизненные ориентиры.

Конкретизируем нашу задачу. Дано:

  • опыт разработки и использования Eludia.pm;
  • современные RIA-библиотеки и железо, способное их вынести.

Требуется: определить красивейший способ разработки учётно-аналитических Web-приложений.

Чуть выше было показано, что вся Presentation-часть, по-видимому, из ядра выносится полностью. Соответственно, остаётся только Content. А есть ли у нас по этой части что-либо, достойное выживания? Может быть, мы просто привыкли к определённому API, а кругом всё уже давным-давно гораздо лучше? Не думаю, что это так. По крайней мере, мне хотелось бы всегда иметь под рукой:

  • Model;
  • sql и ещё кое-что из нашего SQL API;
  • ещё кое-что из нашего API, вроде dt_add, upload_file и send_mail.

И ещё — не зависеть от платформы. Никогда.

На чём писать?

Замысливая столь масштабную смену технологии, имеет смысл допустить и переход на другой язык программирования. Он должен:

  • поддерживать списки и хэши на уровне базового синтаксиса;
  • содержать элементы функционального программирования (closures);
  • быть портирован на JVM и .Net.

Основные кандидаты приведены выше в таблице. И наиболее привлекательным из них мне кажется javaScript. Он не просто встроен в любой современный Web-браузер и в любом случае будет использоваться в Presentation. Есть минимум 2 способа писать полноценные Web-приложения (с транзакционной реляционной БД) на javaScript и использовать их без сервера:

Поначалу трудно воспринимать js как язык серверного программирования (его вообще часто не понимают), однако в этом плане в последнее время намечаются серьёзные сдвиги:

И вот что ещё знаменательно: js-движки последних поколений (сначала v8, потом конкуренты) уже JIT-компилируют не в байт-код, а прямо в коды железного процессора. С регистровой оптимизацией циклов и прочими серьёзными вещами.

У нас есть план?

Мне кажется, стоило бы заняться разработкой на js вот чего:

  • аналог нашего SQL API для драйверов разнообразных СУБД к разнообразным реализациям js (сейчас там дикий зоопарк);
  • wish для разнообразных СУБД;
  • Model и assert;
  • sql.

Частичная реализация

Проект Ludi.js: https://github.com/do-/ludi

Персональные инструменты
Пространства имён

Варианты
Действия
Навигация
Разработчику
Администратору
Инструменты