Cloud Clients

The term cloud has many definitions in a computing context these days. Some refer to the various social networks as a cloud which I think is overly broad. Perhaps the best definition is the simplest; "a group of interconnected nodes". A "cloud" of nodes is a design construct, not a deployment one. The number of nodes and their respective locations should have no impact on the terminology used.

So what are the roles of these nodes that make up clouds? Typically, a node plays the role of a server. They act when they are requested to act. Users of these clouds are actually outside the cloud. The servers within the cloud then act on behalf of these client requests.

So is it possible to have these outside clients join into the cloud in order to share some of these computational resources? It certainly is and that is what peer-to-peer computing is all about. In this distributed computing model, the client is them most prevalent role in the entire system. Forget about the managers that allow these clients to discover one another. The manager are necessary but the clients taking on more than just a simple dummy role is what is interesting. It allows scale within the cloud to spread like disease.

Python Javascript Bundle

The jsBundle Python package is a nice little utility for building deployment-ready javascript modules. As the same suggests, jsBundle is used to bundle several javascript modules that make up the front-end of a web application. Many web applications will simply serve the javascript modules as is. That is, the source code of the javascript modules is distributed in the application with no modification or compression. This approach is perfectly acceptable when the logical arrangement of javascript modules are simplistic. When there are many javascript modules, some of which might be fairly large in size, a more managed deployment approach should be taken.

There are several javascript compression and bundling utilities available today. There also exist server-side libraries that allow server code to be written that will actually generate the required front-end javascript. The main problem with this approach is that there are too many corner cases where the inflexibility of these server-side javascript libraries do not allow for optimal javascript to be generated. Some web applications might have a well organized javascript package arrangement that is well balanced. What the developers might do is use a javascript compression utility to compress each javascript module. The problem here of course being that it is hard to maintain this approach.

The jsBundle makes this much easier by allowing for any arrangement of javascript modules to be compiled into a single, compressed module that is given to the application front-end. Additionally, jsBundle is also capable of generating API documentation, an area largely neglected for javascript. One final aspect of jsBundle worth noting is that it is especially handy to use if your server-side application is implemented in Python. jsBundle can then easily integrate with the web application distribution.

Web-based applications a good idea?

An entry on infoworld doesn't think so. Apparently the web browser sucks for applications and anyone using them are reverting back to the client server model. Well, it is a client (the browser) and it is a server (whatever). The strong case for the web application in the browser is deployment. There is no easier way to distribute a GUI than the web browser. Unless that is, everyone in the world used Windows.

Of course, the case against the browser is strong too. The same interoperability problems that operating systems experience are shared in the browser domain. In short, your HTML/CSS/AJAX GUI may not work across all platforms (platforms being web browsers in this case).

In terms of GUI interoperability and deployment, the same problems persist. There is no easy way to make everyone happy. And that will always be the case as long as people use different operating systems. There exists no simple unifying solution. Again, with web browsers, you have the interoperability problem. With interpreted languages, it is quite simple to achieve interoperability amongst various operating systems. I think the problem there is deployment. It is a lot tougher to deploy desktop applications that use any kind of data center.

The main problem I see with the suggested solution in the infoworld entry is that there is no mention of distributed data. Lets say I take the advice from the entry and all our customers now use our new Java desktop application. Where did the data go? Any modern requirements will scream distributed data. And that is another complexity there is no alternative for.

All these challenges, distributed computing, distributed deployment, and interoperability, they have been around for a while now. I agree with the author in that for the most part, web browsers suck for any kind of reliable user interactivity. However, I still don't see any solutions over the immediate horizon that will make the browser go away.