I will present a very simple idea, possibly already somewhat doable with current technology (but enhancements to current technology would make it more efficient and robust). The problem is: AJAX applications (whether in OpenLaszlo, Backbase, Morfik, or anything else) have a sizeable browser-side code base that has to be downloaded each time an application is accessed.

It is a considerable burden on the user: she/he has to wait for the code to download and depending on her/his subscription this also decreases the quota she/he has for the month or costs money (e.g. for mobile users). Bad for the application hosting company too: needs huge resources to transfer material that virtually does not change for months and can be comparable in size to the actual data that has to be transferred. This is also bad for the whole Internet/intranet networking infrastructure as well because of the traffic. I see this one of the biggest issues in the proliferation of AJAX/smart client applications.

What can we do to enhance this situation? Let’s build a fundamental component of the WebOS: the standard of application caching in the browser (WOSTOC). Browser companies and AJAX framework vendors should work out a common standard for partitioning the code (and auxiliary items like images, sound files, etc.) for applications so that code should be easy for the browser to identify and cache as long as it is not changed.

(As a side note: for many Web 2.0/WebOS application frameworks, the browser will become the virtual machine running JavaScript as the common code base; Morfik’s novelty is recognizing this and going one logical step forward: using JavaScript as the intermediate language/machine code to which it synthesizes form a “traditional” high level language.)

We should avoid two common problems from the past: DLL hell and security issues.

We get to DLL hell if two applications try to share a common library but of different versions. One of the applications will fail due to incompatibilities of the newly installed library code. To avoid this, we should make sure that code is not shared among applications.

There may be several security issues. One is IP protection: the code should be transferred and stored in an obfuscated manner so that reverse engineering and tampering with is made more difficult.

Another related security issue is making sure that tampering with is detected and rectified: the browser should ask for a hash/fingerprint for each file it needs to download and check with its local copy whether the fingerprint matches, and if not, should re-download the complete code. This way we could also get automatic updates for free.

Additional security issues should be uncovered and addressed too.

Using tokenization as part of the obfuscation could also help in speeding up the execution of the code (backward browser compatibility is an issue, though).

We should define this new standard in a compatible way: browsers that do not support the WOSTOC protocol would see the applications as they see them now, probably a bit better structured (and thus even their limited caching abilities would work better).

What is the difference between WOSTOC and current caching technologies in the browsers? Technically virtually nothing, and that is good. Browse developers and application framework developers should agree on a common protocol, examine and iron out security issues and application framework developers should make sure that the applications are well partitioned so that RTL code can be easily cached, application code regularly updated as needed, and dynamic application data is excluded from the overhead of caching checks.

In summary, we would get to a much more responsive web experience with much less load on the infrastructure and better performance on the client, too. Since all contemporary browsers already support caching and most of the protocol is more an organizational/standardization issue than a technical one, WOSTOC 1.0 could be defined and implemented very quickly.