Идея давно уже зрела и обрастала экспериментами и вот я решил поделиться мыслями с Хабром, дабы получить пинок в нужном направлении или получить заряд энергии на дальнейшую реализацию своих идей.
Мне нравится JavaScript как весьма лаконичный и красивый язык сценариев. Я часто его использовал, да и сейчас использую, для автоматизации некоторых своих задач. Недостаток проявляется только в том что часто бывает недостаточно объектов и методов для выполнения поставленных целей. Но в этом случае меня выручали самописные COM-объекты. Еще для полноценных приложений необходим пользовательский интерфейс. В качестве простого интерфейса для небольших приложений весьма удобно использовать HTML. Все это есть в Windows начиная с 98-й версии и называется — HTA (Hypertext Application).
Недостатком HTA я считаю, что для выполнения такого приложения необходимо несколько файлов, сам HTA-файл, картинки для оформления интерфейса и COM-объекты с необходимым нестандартным функционалом. Причем COM-объекты необходимо регистрировать в системе, что делает практически невозможным создавать простые в использовании приложения.
Вот если бы упаковать все это в один файл и запускать его специальным приложением. Это возможно сделать следующим образом: все необходимые файлы: html, css, картинки и сам скрипт сценария сохраняется в zip-файл, а все часто используемые объекты и методы реализуются прямо в исполняющем приложении. Это приложение представляет из себя своеобразный фреймворк с необходимым функционалом. Все это было мной реализовано и получило название JSA — JavaScript Application.
Но дальше «Остапа понесло...». А что если интерфейс приложения разместить на веб-сервере и оттуда же загружать сценарий самого приложения. HTML-интерфейс обращается к функциям моего фреймворка и выполняет необходимые действия. Например, пишем приложение — Ресайзер картинок, загружаем приложение с сервера, а вся работа выполняется на компьютере пользователя. Т.е. нам не нужно аплоадить картинку на сервер и затем скачивать обратно, все это в целом повысит скорость работы приложения. Это похоже на модные сейчас расширения для браузеров типа Google Gears. Однако в этом случае остро встает вопрос безопасности. Если дать скрипту с удаленного сервера хозяйничать на пользовательском компьютере, то этак и до троянов недалеко.
Поэтому я пришел к выводу, что мы должны разделить HTML-интерфейс и код самого приложения имеющий доступ к небезопасным функциям. HTML-интерфейс обращается к функциям приложения через специальный объект, в котором скрипт приложения описывает только самые необходимые высокоуровневые методы. Сам скрипт приложения пакуется и подписывается цифровой подписью, чтоб злоумышленники не смогли подменить его на сервере.
Что мы получаем в итоге. На компьютере пользователя ставится небольшое приложение-фреймворк умеющее загружать с веб-сервера упакованный и подписанный сценарий который при запуске открывает окно с HTML-интерфейсом который расположен так же на веб-сервере. В моем случае, так как я использовал для реализации HTML интерфейса ActiveX WebBrowser, а в качестве исполняющей системы сценариев ActiveScript, то исполняющий файл получился весьма небольшой, около одного мегабайта.
Какие преимущества можно получить разработчику от такой схемы создания приложений? Во-первых, много вариантов монетизации таких приложений, например, размещение рекламы и гибкого управления ей, т.к. интерфейс загружается с веб-сервера, то можно динамически менять рекламные обьявления или давать доступ к приложению за SMS, используя простой метод SMS-замка. Во-вторых, мы можем легко обновить приложение на сервере и оно обновится сразу у всех пользователей. В третьих, мы имеем полную статистику использования нашего приложения, путем просто анализа логов сервера.
Все это похоже на Adobe AIR или Java FX, но в моем случае получился весьма небольшой фреймворк (1 Mb) и идея размещения интерфейса на сервере, а не включенного в само приложение, дает определенные преимущества.
Мне нравится JavaScript как весьма лаконичный и красивый язык сценариев. Я часто его использовал, да и сейчас использую, для автоматизации некоторых своих задач. Недостаток проявляется только в том что часто бывает недостаточно объектов и методов для выполнения поставленных целей. Но в этом случае меня выручали самописные COM-объекты. Еще для полноценных приложений необходим пользовательский интерфейс. В качестве простого интерфейса для небольших приложений весьма удобно использовать HTML. Все это есть в Windows начиная с 98-й версии и называется — HTA (Hypertext Application).
Недостатком HTA я считаю, что для выполнения такого приложения необходимо несколько файлов, сам HTA-файл, картинки для оформления интерфейса и COM-объекты с необходимым нестандартным функционалом. Причем COM-объекты необходимо регистрировать в системе, что делает практически невозможным создавать простые в использовании приложения.
Вот если бы упаковать все это в один файл и запускать его специальным приложением. Это возможно сделать следующим образом: все необходимые файлы: html, css, картинки и сам скрипт сценария сохраняется в zip-файл, а все часто используемые объекты и методы реализуются прямо в исполняющем приложении. Это приложение представляет из себя своеобразный фреймворк с необходимым функционалом. Все это было мной реализовано и получило название JSA — JavaScript Application.
Но дальше «Остапа понесло...». А что если интерфейс приложения разместить на веб-сервере и оттуда же загружать сценарий самого приложения. HTML-интерфейс обращается к функциям моего фреймворка и выполняет необходимые действия. Например, пишем приложение — Ресайзер картинок, загружаем приложение с сервера, а вся работа выполняется на компьютере пользователя. Т.е. нам не нужно аплоадить картинку на сервер и затем скачивать обратно, все это в целом повысит скорость работы приложения. Это похоже на модные сейчас расширения для браузеров типа Google Gears. Однако в этом случае остро встает вопрос безопасности. Если дать скрипту с удаленного сервера хозяйничать на пользовательском компьютере, то этак и до троянов недалеко.
Поэтому я пришел к выводу, что мы должны разделить HTML-интерфейс и код самого приложения имеющий доступ к небезопасным функциям. HTML-интерфейс обращается к функциям приложения через специальный объект, в котором скрипт приложения описывает только самые необходимые высокоуровневые методы. Сам скрипт приложения пакуется и подписывается цифровой подписью, чтоб злоумышленники не смогли подменить его на сервере.
Что мы получаем в итоге. На компьютере пользователя ставится небольшое приложение-фреймворк умеющее загружать с веб-сервера упакованный и подписанный сценарий который при запуске открывает окно с HTML-интерфейсом который расположен так же на веб-сервере. В моем случае, так как я использовал для реализации HTML интерфейса ActiveX WebBrowser, а в качестве исполняющей системы сценариев ActiveScript, то исполняющий файл получился весьма небольшой, около одного мегабайта.
Какие преимущества можно получить разработчику от такой схемы создания приложений? Во-первых, много вариантов монетизации таких приложений, например, размещение рекламы и гибкого управления ей, т.к. интерфейс загружается с веб-сервера, то можно динамически менять рекламные обьявления или давать доступ к приложению за SMS, используя простой метод SMS-замка. Во-вторых, мы можем легко обновить приложение на сервере и оно обновится сразу у всех пользователей. В третьих, мы имеем полную статистику использования нашего приложения, путем просто анализа логов сервера.
Все это похоже на Adobe AIR или Java FX, но в моем случае получился весьма небольшой фреймворк (1 Mb) и идея размещения интерфейса на сервере, а не включенного в само приложение, дает определенные преимущества.
