HTML5 Storage Complexity

With new emerging HTML5 standard, Google is focusing on using the standard for local, client-based data storage. Its nice to have some flexibility in the browser in terms of how data is stored and how to go about retrieving that data. Having a database API would no doubt help in that effort.

But is that getting too complex? Having a feature-rich data store in the web browser might take too much of the design focus away from the overall service architecture. Instead, I think it makes more sense to store URIs on the client. These URIs represent the potentially complex resource states that live on the server.

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.

RESTful Python Objects.

Designing RESTful resources that behave like the web in this day and age makes for good API design practice. The resulting API has a very high level of simplicity that is sought after and valued by many developers. However, what about the client end? Can they too benefit from this elegant design? They sure can. Just like anything else in software design, APIs can be abused or they can be used as intended. So, why not make the client work similarly to how the resources themselves behave? Better yet, why not make them identical?

This can be achieved by mapping individual resources to Python instances. This makes for a good abstraction mapping. One resource, one Python instance. But this doesn't really help the Python developer if there are "special" methods they need to invoke on the instance just to interact with the actual resource. This instances acts as a proxy and so both the instance data and the instance behavior should be the same as the resource. This can be done by using the following principles:

• The constructor could issue a POST HTTP request to create a new resource using the constructor parameters.
• The attribute retrieval could be overridden to issue a HTTP GET request.
• The attribute setting could be overridden to issue a HTTP PUT request.
• The object deletion functionality could be overridden to issue a HTTP DELETE request.

That's it, the instance can then behave like a regular Python instance and be a RESTful resource at the same time. Mind you, these are just principles and not and ideal implementation, obviously. So, what is needed is an HTTP library of some kind to fully implement each of these methods. There will no doubt be variations to these methods as well. For instance, there is often the requirement of retrieving lists of resources as opposed to a single resource.

The following is a simple example illustrating these principles.

#Example; RESTful Python instances.

class RESTful(object):
   def __init__(self, uri, **kw):
       #Issue a HTTP POST request construct a new resource.
       print "POSTING..."
      
   def __getattr__(self, name):
       #Issue a HTTP GET, possibly a conditional GET to 
       #retrieve the resource attribute.
       print "GETTING..."
      
   def __setattr__(self, name, value):
       #Issue a HTTP PUT request to update the resource
       #attribute.
       print "PUTTING..."
      
   def __del__(self):
       #Issue a HTTP DELETE request to destroy the resource.
       print "DELETING..."
      
class BlogEntry(RESTful):
   def __init__(self, uri, **kw):
       RESTful.__init__(self, uri, **kw)
      
if __name__=="__main__":
   entry=BlogEntry("/blog", title="Hello", body="World")
   entry.body="There"
   body=entry.body

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.