Browsers as UI to Web Cloud Applications.

[BearState]

The secret of NAIM ( Native Application Interface Management ):

In a previous post, the political ramifications of defining a specific API for the VM OS layer was assessed. The goal was to achieve a standard homogeneous API that closely paralleled the OS interface and would allow condensation of existing technologies to a simpler more easily understood and usable interface. But in that post, it was not clear how to procede.

There are actually a couple issues.

1) It is required to define which API style should be used on the layer without creating a project collaboration rift.

2) The Native OS API may be used for a large percentage of applications which run client side off the desktop using native library routines, but require web access and functionality, making them more than simple desktop applications.


And this in fact, suggests a universal solution which is based on an API that may be dynamically managed to suite developer/user preference. It is known for example that most code will be at least byte-code translated before being dispatched. This suggests then that coding may be done in syntactic variants. NAIM would provide functionality that allows a programmer to choose an interface style, but only if there is a one to one correspondence for each variant such that they may be mapped to a common interface requirement. NAIM would provide web application developers the ability to choose between APIs that may be syntactically Unix-like, Windows-like, Apple-like, Java-like or Koala basic. Developer comfort levels would be catered to there would be little requirement for any developer to learn new API syntax. Through NAIM, Koala would be multi-linqual.

NAIM would further allow developers to enter coded sequences directly on Koala browsers or servers and execute them in test bed or direct control scenarios, having full SQA functionality including full featured debuggers, built in and at the ready. This type of expanded functionality need not be special or additional in nature. As a standard Koala feature, this additional versatility of the browser serves not just developers, but knowledgable users as well. Naim could in fact be tailored to present an extremely simple interface which would allow simple user defined actions within an application or directly upon the browser. There is in fact, no reason why the developer may not define their own syntax through NAIM. That syntax however, would be limited in scope to the developer's host, intranet or systems under the developer's influence. One might well consider how this might figure in the deployment of special devices such as hand-helds or perhaps, navigation systems in vehicles, et al.

[BearState]

Thus far, direct client/client communications with Koala have been discussed with traditional servers acting as startup connectivity catalysts and conduits for client/client dialogues once connections have been made.

But there are some current and old technologies which deserve some speculation with regard to client/client dialogues. The telephone switching system will likely never be the same again. The telephone industry today is tetering on the edge of its own demise as cell phone, iphones and other hand held technologies spring up by the dozens to compete for communication service business. And whether its land lines or via statellite, the heart of telephone interchanges are naturally positioned to take on the role of servers for the startup connection role for web dialogues directly between clients. It's just the refreshingly natural revival ticket that the big traditional phone companies might be praying for.

And with support for control system support, hand helds will take on a whole new range of roles and services, for industry, service and personal connectivity and interchange. Hand held devices will move to the fore which act as remote probes, switchers, medical instruments and ... well, the list can be quite endless.

Fault tolerance of such systems might be enhanced through backup connectivity using different infrastructures, land, satellite and others. It's a seed waiting to germinate after being sewn by the introduction of Koala.

[BearState]

Coming full circle in this discussion, back to AJAX and how it doesn't satisfy my idea of fully robust application development methodology or even limited Web Cloud or Rich Application Interfaces, consider the following ...

Some folks are aware that there are at least five ways to trigger a client to server request which typifies best practice AJAX methods.

1) Hidden Frame with callback
2) Hidden IFrame with Callback
3) XMLHTTPREQUEST Object ( XHR )
4) src attribute in image create
5) Javascript Inline Scripting with or without the DOM

The last two of these are especially interesting as they tell the tale of how some folks have bandaided in functionality by searching for ways to trigger a request to the server. The original preconcept for AJAX itself, was not an intentionally built in feature of browsers. The Image Creation technique is a great example; it does not create an image for viewing, only an empty image for triggering the request. As part of the technique, a web programmer may use the image's size to imply status ... success, an error, or whatever. Status codes can't be returned any other way. You gotta love that sort of stuff. It works! Albeit, it's definitely a creative sort of solution that uses images in a bizzarre sort of way ... and its done even though images take up more load time than straight code!

The virtues of the last two methods are that unlike the first three, you can make requests to different domains. With the first three you can only use AJAX within the same domain. It really makes a developer wonder why nobody has yet to implement functionality into the browser that accomplishes this functionality with a direct 'no smoke and mirrors' syntax.

XHR is nice because it give status and a straight forward syntax methodology, but has liminations and disadvantages. That's why some developers include all five techniques in their bag of tricks.

Like I said, you gotta love this stuff. It works! But it is rather odd and well ... you come up with a word for it.

And this sort of spread for doing things in web development is not limited to AJAX alone. The choices are many. It's easy to see why Koala has as one of its prime objectives the condensation of all these overlaps into a single API.

[BearState]

Looking into the crystal ball, there's a thing on the horizon that Koala will enable called Virtual Ownership Storage Systems ( VOSS ). Technologies already exist today that are in fact, precursors to VOSS, in particular, websites which allow users free disk space to cache and share photographs and to purchase downloadable video and music tracks which can be used to create CD or DVDs. With Koala, there is no need to create CDs or DVDs. Matter of factly, it becomes preferable not to create such transferable mediums.

Let's get a better idea of what VOSS is all about and how Koala enables VOSS technology. Koala as has already been pointed out, supports control systems and bi-directional role reversal protocols. The future of hand held and other remote devices has been barely touched upon. But lets take a look at a common appliance, the television set, for starters. Currently, we tie into a cable television service which serves up programming that is fixed or can be modified via 'pay per view' options. Users of cable television are limited to one vendor and the finite programming it provides which varies on a periodic basis. In the future, television programming will become a network available service. The finite programming of cable television will be supplanted by multiple independent services available on the network. Channel changing will become a search function where the user searches for the programming they desire and can tie into it at any time to get pre-recorded programs or tie into live broadcasts. The televsion remote becomes a Koala hand-held client which is geared to communicate directly with the entertainment center of the future web surfer who may pay membership fees to access specific programming over the web or optionally, tie into free programming. And that programming is no longer finite and limited by subscription to a specific cable company. It is virtual and open to many different vendors of network televised communications. And it is two-way. Offers may come in and be displayed for user selection.

So what happens to an individual's CD and DVD collections and all those CD Wallets and storage stands? They go away. The medium for such things becomes VOSS. When a person wants to play a CD album, they connect to their VOSS storage vendor and the tracks are served up over the net. Portable Players expand to include television, not just music tracks and of course, that includes boom boxes and in-dash automobile based systems. There's no need to pack along a CD wallet on those trips out of the house. Your remote device accesses your personal VOSS over the net and you have access to your tunes and videos.

VOSS will have many other purposes, including document storage and voice/video messaging. And of course, purchased software applications may reside on VOSS, including games of many types. But one very interesting economical implication of VOSS is virtual trade. Sound and Video tracks stored on VOSS don't wear out and there's potential for a type of web economy to evolve based not on currency, but virtual ownership objects ( VOO ). The economic implications will be unusual, especially since VOO assets as they exist as a readily duplicatable medium, are counterfitable. In any regard, a discussion of these ramifications in the legal world changes is beyond the scope of this post.

Should a user desire to pack their VOO assets with them to some remote place where they feel they will not be able to obtain web access to VOSS, the answer is simple via an already extant technology, flash drives. Flash drive technology is much more compact than CD and DVD mediums and allows the user to pack along a huge library of VOO assets. And Koala with its VM OS interface provides a very nice way to access these libraries on the client side, ie. the playback device. Plug-in and Play! The biggest challenge is that of providing good portable energy sources ( batteries ).

[BearState]

Could a large collaborative project to redefine browser, server and web technologies to enable fully robust web applications spike the economy?

The answer is certainly, even with the outsourcing of globalization, there's a lot of manhours to be invested and the opportunities for new start ups are certainly there.

Taking a brief inventory ...

1) Software Engineering and Comuter Scientists
These sectors of the economy benefit from needs to redefine browser internals and server infrastructures. As normal desktop applications, large applications beyond those defined under the umbrella of Web Cloud and RIA find the new infrastructure available, a large number of traditional applications will see revisions to utilize web communications and a large number of new applications will be spawned. Security issues will peak that sector of the industry without doubt as the new technology will require changes in how network security is implemented and its depth.

2) Hardware Engineering
Improvements in network bandwidth and QoS, place a need for changes in infrastructural hardware. Security appliances which monitor network traffic and selectively remove or inhibit illicit or harmful packets will come to fore as new technology. But the largest hardware sector growth will be seen in new appliances, ranging from hand held devices to traditional household appliances which do not normal function over the internet. Industrial and Scientific control applications will find a fertile ground for new applications and will require new devices for controlled automation of processes and collection of information. Probes, monitors and instrumentation will also find new methods of implementation.

3) Service
ISPs, Advertising, Entertainment, Communications, Automated Processing and Information Gathering are likely to be among the largest featured service growth areas, but there is certainly a large list here to include, eductional, government, medicine and others which will benefit from the new technologies predicted here. The transportation and shipping industries for example will find new ways to monitor, dispatch and control travel from reservations, priorities to tracking, futuring expenses and so forth.

4) Manufacturing
When hardware changes, manufacturing benefits. No need to say more.

5) Administrative
This area is difficult to predict, but the legal sector might see some changes as security issues come to involve legal processes to a larger degree. As well, intellectual property rights can be predicted to see some changes as elements which are traditionally not shared suddenly find expression in a widely shared global market.


The ripple out certainly has potential for affecting many other areas.

As a follow-up question, does it make sense to persue such a large collaborative project with the intention of stimulating economic growth as one of its primary goals?

It is natural for individual corporations to persue projects for their own financial growth and wall technologies to preserve their rights to those technologies. When a large corporation stimulates the economy, some might believe that they preferentially do so through community, providing grants and other foundation-like contributions to stimulate production of the educated labor and management resources they require and infrastructures related to community to benefit their human assets.

If we conclude that a general stimulus to the overall economy is a community benefit that lends itself to those corporate objectives, but on a much larger collaborative and partnered scope, then yes, it does make sense and is even more preferrential. Albeit, it will requiring some steering to allow corporate competitive protections.

[BearState]

Google's Chrome Browser, although it touts the goal of providing a favorable browsing environment for web applications, does not achieve what Koala is outlined to do. Chrome will provide improved security in a way that is favorable, but it doesn't monitor the stream and eliminate malware and other problematic packets from the stream. Instead, it sandboxes and restricts activity in a way that also limits functionality that Koala would prefer to promote. It also favors tabs over secondary windows, a philosophy that may well restrict how tool pallettes and app interactivity is achieved.

Chrome does introduce a new Java Vertual Machine which might hold some surprises, but it doesn't sound like a VM OS implementation that would allow fully robust web savy apps. Gears by being included in the browser will allow greater client side disk usage, but ... ???

The future lies in opening up a mutual embrace between the OS environment and web environment. Chrome doesn't do this. It's a minor step on the path and puts google in the browser game. Interclient communications will still rely on client to server requests, AJAX client polling of the server and is in no way, server polling of clients. No control apps are on the horizon. No client to client interconnects, except via client to servier AJAX style polling. The share data and resource store will remain as a server component with the concept of client side data and resource store ... out of the question. In short, Chrome, like current browsers, adheres to a paradigm where the client side initiates and sustains all web activity and only by direct connection to a server. It will not be possible to have both the client and server be independently active in initiating communications. Apparently, the fact that a client can be offline still spells IMPOSSIBLE to browser theorists and designers.

[phoebe]

The browser developers, server developers and the big search engine players that want to be the app portals of the future. And of course, the major players in the application and operating system products lineage, have to have their input.