— Home of XPL (eXtensible Process Language)
It's like XML, but you can store source code in it.
I have already provided one blog entry on the browser-based GUI, about how it's a time killer for development but that there is a reasonable rational for doing it. Now, just a quick word on its specific design. There is actually more than a bit of thought behind it. It has survived several prototyping activities. The reason this is interesting, is that it adds to the idea that browser components can be reused - saving developers time and effort when creating new applications.
Although HLL is really separate from the browser-based GUI, it is the intent of the project to provide reusable software even for the GUI. Especially for applications built with HLL, there seems to be a good opportunity to do so - since the "high level logic" of the application is somewhat predictable. The HLL /GUI pair can even use a common general message format, perhaps based on FIPA for example, or customized to support a company or development house specialization. This idea just leans on good design practice - thinking in layers. Very general communication and processing support can be provided by the HLL GUI. Specialized organizations can extend that capability to provide reusable support for the type of software that they develop and maintain.
The use of frames provides an easy way to modify the content; simply load a different html page into the frame. Another frame can maintain state variables that will allow returning to the same state if you reload an earlier page, or provide an up-to-date state instead (or use AJAX to deliver to / fetch from server or app. - yes, HLL apps. can even incorporate typical, common, everyday ordinary request-response processing). Frames can be resized on the fly or frame content can be expanded to a separate full-screen browser window. I've also been using one frame (upper left with a logo in it) to contain the applet that accepts data pushed in from the outside. It also contains functions to channel the data to the frame.method() where it is used. The upper right frame, which displays title and menu, is what I use to store generally useful javascript functions and state information for other frames.
It can also load or reload the upper left frame(s) to control use of applets. Just to illustrate; imagine a process of switching from one human operator to another in which there is a need for both operators to be online temporarily during the change over. One could switch from a single secure URLConnection to Multicasting during the transition, giving full use to two terminals. Once the new operator is in full control, the communications link is switched back to a URLConnection at the new operator's terminal. There may be a need for multiple applets for some applications. I've typically met that need by stacking smaller frames into the same small upper left corner. (Size doesn't matter).
Here are some visualizations for robot related applications that I created when presenting the HLL concept (in the context of a robotics project) in 2006.
The first suggests use of HLL and the browser-based GUI in a mobile surveillance / security robot application (in a German airport in this illustration).
The next illustration suggests use of HLL and the browser-based GUI in a development tool application for robots that can learn and adapt (using genetic programming). - This comes close to the original concept GUI: with the thought of providing a tool to support development of HLL applications.
The next illustration suggests use of HLL and the browser-based GUI in a related research tool application.
The next illustration, from one of my working prototypes, shows a screen expansion to get a closer look at some XML.
This comment has been removed by a blog administrator.
ReplyDelete