Every engineer appreciates good design. When it come to architecture and design of web applications I have seen very few that have taken scalability into consideration from the very beginning. It is seems like the web application was written for a single user – huge collection used for trivial operations, massive objects maintained in session, the list can go on. Given that I started programming for the desktop, I have been guilt of these design gaffes too.
However, as we move towards applications that may have 1000s of users if not millions we have to look at scalability seriously.
Web based applications today are promising but still too immature to challenge the performance of desktop applications when it comes to the richness of the User Interface and the diversity of applications.
Apart from the limitations of what the Browser can and cannot do – some of the other major challenges are:
Connectivity – For the apps to work, you always need a connection. Further the quality of the quality of the connection dictates what can and cannot be done.
Process intensive tasks – Like image processing, data analysis, etc take too long and can make the pages time out and further server scalability a challenge.
Given that Google is so vested in online apps and they have the resources to actually address these problems – They exactly did exactly that with Google Gear. This provides a elegant way to work with web pages offline, thus enabling the web applications to work with limited or no connectivity and at the same time do some processing off line.
It is really exciting as it offers a way to solve may problems that I had in the past.
For example – In an application, I had a mobile user that had limited or no connectivity with a laptop collecting data onsite (survey) that was huge (hi-res pictures and video). To upload it we had a “web version” and a “desktop version”. The desktop version was used on-site and would sync with the server, once the mobile user got back to the “home station”. The home-station was the same laptop with a wired high-speed connection.
The problem with this solution? We had to maintain two separate application. Further we were limited to certain platforms for the desktop application which limited our choice on the server (as we wanted the same developer skill sets).
But that can change with Google Gear and I think they have really addressed very real issue with Webware. How does it solve your problem?
I was browsing the blogsphere and came across http://www.BlueDot.us. It is a social bookmarking site with a lot of AJAX and the ability to have links, representative thumbnails from the bookmarked page and ofcourse – tagging.
When I hit the site, it was a bit slow, but that is understandable given that they really were not ready for the kind of attention (they mentioned on their blog.) Good luck to them, hope they find what they are looking to achieve with the site.
Reminds me of 1999-2000, the entrepreneurial sprit never fails.
Vikas is a good friend and co-entrepreneur who engages uncertainty like me (don’t wish to wed it!) . He wanted to know the capacity of CDMA and what made it better. While I am not a expert on what is best for the mobile MAC (Medium Access Protocol) enviroment, CDMA does take advantage of many phenomenon that occur in wireless cellular networks -
Relax Bandwidth Capacity - Unlike TDMA, there is no hard limit on the bandwidth. One can trade off the SNR (Signal to Noise Ratio) to accomodate addtional users.
Voice Activity Dection – Since humans talk only 35% time of time, it does cause enable to increase the the capacity by almost 5-6 folds in CDMA. However it does not hold true if you are downloading rich media. Design so much depends on the Traffic pattern, no wonder my Advisor keeps asking me – “What traffic pattern are you assuming?”
There are a several other aspects and a small post would not do justice to it. The best place to start is at the source paper : Overview of Cellular CDMA that appeard in the IEE transactions on Vehicular technology in May 1991.
How well one can solve a problem really depends how well one can abstract the noise and distill to the core of the issue. While this is true in every aspect of problem solving it is particularly true in Software Development. All the rage about AJAX – it is RPC, it is Web 2.0 and every other term coined to make it sellable.
Basically it is an excellent example of abstraction. It enables the decoupling of UI from programming logic. So now the user who interacts with a web application does not have to depend on what is on the server and what is on the client.
If I may speculate, this abstraction may finally refine the web to its true potential of a socio-technical, distributive-collaborative application platform.
I was browsing the blogsphere and came across