July 12, 2009 at 09:25With thoughts of the RIA
The idea has long been ripened and overgrown with experiments, and so I decided to share my thoughts with Habr, in order to get a kick in the right direction or get a boost of energy for the further implementation of my ideas.
I like JavaScript as a very concise and beautiful scripting language. I often used it, and now I use it, to automate some of my tasks. The disadvantage is manifested only in the fact that often there are not enough objects and methods to achieve the goals. But in this case, self-written COM objects helped me out. For full-fledged applications, a user interface is required. It’s very convenient to use HTML as a simple interface for small applications. All this is on Windows since the 98th version and is called - HTA (Hypertext Application).
The disadvantage of HTA, I believe that to run such an application requires several files, the HTA file itself, pictures for the design of the interface and COM objects with the necessary non-standard functionality. Moreover, COM-objects must be registered in the system, which makes it almost impossible to create easy-to-use applications.
Now, if you pack it all into one file and run it with a special application. This can be done as follows: all the necessary files: html, css, pictures and the script script itself are saved in a zip file, and all commonly used objects and methods are implemented directly in the executing application. This application is a kind of framework with the necessary functionality. All this was implemented by me and was called JSA - JavaScript Application.
But then "Ostap suffered ...". But what if the application’s interface is placed on a web server and the script of the application itself is downloaded from there. The HTML interface accesses the functions of my framework and performs the necessary actions. For example, we write an application - Image Resizer, download the application from the server, and all work is performed on the user's computer. Those. we don’t need to upload the image to the server and then download it back, all this will generally increase the speed of the application. It looks like trendy extensions for browsers like Google Gears now. However, in this case, the security issue raises sharply. If you let the script from a remote server host on a user computer, then it’s not far from the trojans.
Therefore, I came to the conclusion that we must separate the HTML interface and the code of the application itself, which has access to unsafe functions. The HTML interface accesses the application functions through a special object, in which the application script describes only the most necessary high-level methods. The application script itself is packaged and signed with a digital signature, so that attackers could not replace it on the server.
What do we get as a result. A small application-framework is installed on the user's computer that can load a packed and signed script from the web server which, when launched, opens a window with an HTML interface that is also located on the web server. In my case, since I used ActiveX WebBrowser to implement the HTML interface, and as the ActiveScript scripting system, the executable file turned out to be very small, about one megabyte.
What benefits can a developer get from such an application creation scheme? Firstly, there are many options for monetizing such applications, for example, advertising and flexible management of it, because Since the interface is loaded from a web server, you can dynamically change advertisements or give access to the application via SMS using a simple SMS lock method. Secondly, we can easily update the application on the server and it will be updated immediately for all users. Thirdly, we have complete statistics on the use of our application, by simply analyzing the server logs.
All this is similar to Adobe AIR or Java FX, but in my case it turned out to be a very small framework (1 Mb) and the idea of placing an interface on a server, and not included in the application itself, gives certain advantages.
I like JavaScript as a very concise and beautiful scripting language. I often used it, and now I use it, to automate some of my tasks. The disadvantage is manifested only in the fact that often there are not enough objects and methods to achieve the goals. But in this case, self-written COM objects helped me out. For full-fledged applications, a user interface is required. It’s very convenient to use HTML as a simple interface for small applications. All this is on Windows since the 98th version and is called - HTA (Hypertext Application).
The disadvantage of HTA, I believe that to run such an application requires several files, the HTA file itself, pictures for the design of the interface and COM objects with the necessary non-standard functionality. Moreover, COM-objects must be registered in the system, which makes it almost impossible to create easy-to-use applications.
Now, if you pack it all into one file and run it with a special application. This can be done as follows: all the necessary files: html, css, pictures and the script script itself are saved in a zip file, and all commonly used objects and methods are implemented directly in the executing application. This application is a kind of framework with the necessary functionality. All this was implemented by me and was called JSA - JavaScript Application.
But then "Ostap suffered ...". But what if the application’s interface is placed on a web server and the script of the application itself is downloaded from there. The HTML interface accesses the functions of my framework and performs the necessary actions. For example, we write an application - Image Resizer, download the application from the server, and all work is performed on the user's computer. Those. we don’t need to upload the image to the server and then download it back, all this will generally increase the speed of the application. It looks like trendy extensions for browsers like Google Gears now. However, in this case, the security issue raises sharply. If you let the script from a remote server host on a user computer, then it’s not far from the trojans.
Therefore, I came to the conclusion that we must separate the HTML interface and the code of the application itself, which has access to unsafe functions. The HTML interface accesses the application functions through a special object, in which the application script describes only the most necessary high-level methods. The application script itself is packaged and signed with a digital signature, so that attackers could not replace it on the server.
What do we get as a result. A small application-framework is installed on the user's computer that can load a packed and signed script from the web server which, when launched, opens a window with an HTML interface that is also located on the web server. In my case, since I used ActiveX WebBrowser to implement the HTML interface, and as the ActiveScript scripting system, the executable file turned out to be very small, about one megabyte.
What benefits can a developer get from such an application creation scheme? Firstly, there are many options for monetizing such applications, for example, advertising and flexible management of it, because Since the interface is loaded from a web server, you can dynamically change advertisements or give access to the application via SMS using a simple SMS lock method. Secondly, we can easily update the application on the server and it will be updated immediately for all users. Thirdly, we have complete statistics on the use of our application, by simply analyzing the server logs.
All this is similar to Adobe AIR or Java FX, but in my case it turned out to be a very small framework (1 Mb) and the idea of placing an interface on a server, and not included in the application itself, gives certain advantages.