by April 1, 2010 0 comments

The web is the focal point for most development activity these days, causing
it to become an amalgam of the most disparate set of clients, servers, and
applications. Already there are so many different online communities being
followed by developers, each having its own set of new technologies, SDKs, and
concepts to work on. If the development continues at the same pace, then pretty
soon, there will be chaos. There will be different islands of information, each
requiring separate plug-ins and web browsers to enjoy full benefits.

One of the reasons behind this is that the web is no longer a static set of
web pages created in HTML. In that era, even if there were minor incompatibility
issues between different browsers, they wouldn’t be so noticeable. People would
still be able to access all the information, even if its presentation was a
little distorted. Developers would still be able to develop, and would have to
do minor adjustments to make their websites compatible across different web
browsers. Look at what’s happening now. The web has become a place to interact,
thanks to all the social media networking sites. Its presentation has become
richer, with more compelling graphics, audio, and video sharing. So there’s
Silverlight from Microsoft, Adobe Flash and AIR, umpteen clients for Twitter, so
many IMs, unified messaging clients, and finally the latest fad on the
web–Cloud Computing, where practically everything happens ‘in the cloud’. If
this continues, then it will impact interoperability of different services on
the web, and with so many online developer communities, security issues will
cause further problems.

Direct Hit!

Applies To: Web developers
USP: Learn how standardization and security issues affect web
app deployment
Primary Link: NA
Search Engine Keywords: web applications

Keeping all this in mind, it’s essential to have a relook at all the
standards, technologies, and coding practices that the web is built on, and
identify the right way forward that would hold the web’s sanctity, and keep it
integrated, interoperable, and secure. One of the movements toward making this
happen is called the Open Web. The philosophy behind this is to keep the web an
open place, with development that follows standards, and the end users are the
focal point for the same. Ultimately, its the users who’re going to make the web
grow bigger. So while the web should retain its de-centralized nature, it should
allow innovation to happen on it freely, with everything well-documented and
accessible to developers.

How should this happen?
I had the opportunity to moderate a panel discussion at Google’s DevFest
event, held in Pune recently, where around 300 developers had participated. The
panelists comprised of experts from Google and two of its partners-OrangeScape
and Impetus Technologies (See names of participants in the photograph). It was
an interesting mix for a healthy discussion, because we had the providers of
development tools on one side (Google), and the users of those and other tools
on the other side (Impetus and OrangeScape). The discussion revolved around how
to make the web more open, with a focus on HTML 5, responsible coding, and
finally Cloud Computing.

The move to HTML 5
One step toward enabling an open web is to upgrade the fundamental base that
the web has been built on-HTML. The current HTML standard is now reaching its
limits and unable to handle the vast amount of development and rich media being
put up on the web. That’s why the next version to the same, HTML 5 has been
taken up by the World Wide Web Consortium, or the W3C, for ratification.

The Google participants, Rajdeep and Patrick, gave examples of HTML 5 usage
and how it can replace the need to use Flash plug-ins. “Virgin America has just
announced that they’re dropping Flash and using HTML 5”, was the response given
by Patrick. The example given by Rajdeep was that of YouTube, which currently
runs on Flash video. He said that there’s a YouTube version that also runs on
HTML 5. Rajdeep also extended this further by saying that HTML 5 can be used in
their own product, Chrome to build extensions, which can be used for offline
access, store user options, etc. He said, “The whole point is that we want to
give users an experience where they have experience similar to desktop apps
similar to browser, where you don’t have Internet connectivity.”

The Panelists from L to R: Patrick Chanezon, Google;
Rajdeep Dua, Google; Anil Chopra (moderator), PCQuest; Mani Doriasamy, CTO
OrangeScape; and Vineet Tyagi, Director-Engg Impetus.

Another example quoted by Rajdeep was of the GeoLocation API, which has been
standardized across browsers that support HTML 5. It uses various features where
the device has GPS, triangular location, etc for building interesting apps, like
in a social web scenario you know the location of the user (with the user
agreeing to be located on the web of course). So more power in the browser will
in effect be good for end users.

“There’s no need to install Flash to use it. Just use plain browser with HTML
5”, he said. He added that for a developer, this is important because you don’t
need all those expensive tools for development.

Use of HTML 5 at OrangeScape and Impetus
OrangeScape’s Mani was of the view that from a browser compatibility standpoint,
not all browsers use HTML 5. That’s why, from a products company or any services
company, it would be very difficult focus on one browser, especially when IE is
a major browser that doesn’t support HTML 5. The HTML 5 platform itself is a
combination of multiple technologies, and Mani said that they use CSS 3 from it,
which will automatically downgrade to the lower version if the browser doesn’t
support it.

Vineet of Impetus said that they were using and experimenting with HTML 5 to
provide better user experience, with features that are not possible otherwise
with today’s tech like Java, Flash, etc. The other aspect he focused on was that
once the HTML 5 spec gets standardized, there’s a lot of potential for
innovation, and to deliver great features.

Other benefits of the Open Web for developers
There’s a lot more to the Open Web than HTML 5, and Patrick highlighted some
of them. He mentioned the widely implemented Geo-Location API, followed by stuff
like Websockets, Accelerometer API, which aren’t yet standardized, but will
become a part of the Open Web. He mentioned CSS3-which is all about
presentation; the new stuff in JavaScript, with some really interesting
features. Patrick finally quoted a Google project called CAHA, for JavaScript
security. He mentioned that the project is aimed at rewriting your Javascript,
so that it’s sandboxed and only accessible for running in social networks.

The need for responsible coding
With so many companies offering free SDKs and tools to develop web apps, how
do you tackle security issues? After all, these tools are free and anybody can
use them. And with every developer community having hundreds of thousands of
followers, security does become a concern. How does one ensure that there are no
rogue applications? How do you ensure that the developer who’s created the web
app has followed the right coding practices or not? How do you know that the
coder is not creating the web app with a malicious intent? Web security
therefore, becomes another key concern when we talk of the open web. For
instance, there can be security issues in developing extensions for Google
Chrome. There’s a way by which a developer can circumvent the Same Origin policy
while coding for Chrome, and nullify cross-site scripting.

Patrick Chanezon of Google gave a very good metaphor
for platform standardization, comparing application development to sea
surfing. He said that when you’re building a web-app, you’re a surfer.
You’re on the wave, and there’s all the sea that’s pretty flat before the
wave. It’s that sea that ensures our apps stay float. That’s the stuff that
doesn’t move. It’s the same sea here, and a thousand KMs away. Today, this
sea means TCP/IP, Intel machines, etc, which don’t move too much. They’ve
been standardized, and everyone takes them for granted. Then there are waves
that start forming, and depending upon your application, you’re at a
different level on the wave. In HTML 5, you’re in the beginning of the wave.
HTML 5 receded from the edge of the wave where there’s the foam, which is
very noisy, you don’t know what you need to support, etc. In the cloud
computing platform, you’re at the edge of the wave, so you need to know what
you’re doing because it may change very quickly. So, depending upon your
risk acceptance layer, you surf in the foam or you stay a little bit behind.

Rajdeep of Google responded by saying that users can report abuse for all
Chrome extensions that they download. So if a user gets the feeling that his
personal information is either being used somewhere else, or being mashed up in
a way he doesn’t want it, then he can report it and the Chrome team can bring
down the extension. Going beyond Chrome, Rajdeep referred to OAuth, an open
protocol to allow secure API authorization. He said that if you’re on one
website and you want to access the info from another website, say to import some
contacts from Gmail or Yahoo!. Then, one option would be for the app to ask for
user’s name and password, go and hit the endpoint and get the contact. This is
an unsafe method. With OAuth, it only asks a user name, redirects to the
homepage of that particular website, and there you enter your credentials and an
OAuth token is sent back.

So there are standards coming around to make things safer. But there are
always things or loopholes that can be hacked. It’s the responsibility of the
community that they’re not abusing these services that are being provided.

OrangeScape and Impetus’ take on Responsible Coding
On the aspect of responsible coding, Mani was of the view that the security
measures you take depend upon the use case. At a high level, HTML 5, Flash, etc
fall under Rich Internet Applications. Their characteristics allow developers to
develop 3 kinds of apps-offline apps, where you don’t have access to the network
all the time; You deploy it on the client, and make sure the versions are
synchronized every time the server comes up. Second is a conversation kind of
application where the client takes care of the document model that’s rendered in
a browser, and the server takes care of incrementally updating the document
model. The example here would be Google Wave, which incrementally updates part
of the document. The third kind is a document oriented application, where the
client has a rich state, meaning there is a model available on the client side,
and the rich client takes care of modifying the client’s date and sending it to
the server.

Depending upon one of the use cases above, you may or may not have access to
the local machine. Offline application need access to the local machine. There
has to be some way by which the developer has access to different access
privileges and you ask the user to explicitly state that, before you can start
doing certain modifications. The ability for HTML 5 or across RIAs to make
available these safe, protected and unsafe code need to be available for making
a developers’ life simpler. As developers, he added, we all love hacks, so the
last thing we want is reduced features in the name of security. That’s why the
need for a use case that balances the security aspect.

Vineet from Impetus was of the opinion that as we grow with the open web
technology, and its community also grows, the safety mechanisms will also come
from the community itself. This is the era of social networking. The excitement
that the open web brings is collaboration. We can as a community help define the
open web. This is a very valid point, and there are already online communities
and non-profit organizations like OWASP, or the Open Web Application Security
Project, whose objective is to improve application security.

Standardization and Cloud Computing
Considering that everything seems to be moving into the cloud, it’s only
natural to wonder where the standards are going as far as various Cloud
Computing platforms are concerned. For instance, Google already has around
100,000 apps on its AppEngine Cloud Computing platform, and likewise, other
platforms have their own strong followings. This most certainly calls for
standardization, so that developers can freely move their applications across
different platforms, and the users are also safe from getting locked into the
services of one particular Cloud services vendor.

On the issue of standardization, Patrick from Google said it was too early to
comment on it because there isn’t much standardization that has happened on it.
Currently, there’s a lot of innovation happening on the Cloud Computing platform
from companies of all sizes.

Everyone’s looking at the space from a different angle, due to which their
offerings are also different. Apart from that, there’s also a need to scale
horizontally, which has to do with moving out from relational databases to
no-SQL based databases. For instance, Facebook uses its own database, Twitter
has adopted from Facebook, while Amazon has something called SimpleDB. So
currently, everyone’s in the innovation mode, and standardization will only
happen over the next two years.

Does standardization kill innovation?

PIf everything conforms to the same standards, then
everybody would be doing the same thing. There would be no innovation. So,
the audience at Google DevFest raised the issue whether standardization
actually kills innovation. Here are the responses from our panelists:

Even if you look at the J2EE history. Somebody can
innovate and change the entire standardization rule, something that happened
in Hibernate. So sometimes a new innovative idea could change the
standardization, so we should be open enough to accept that.

Mani Doriasamy, CTO OrangeScape

There are some innovators who really push forward with
unique offerings. Adobe is there with Flash, Apple is another example.
Standardization is in the middle, which is between the stuff that’s
completely standardized, and the completely proprietary stuff. HTML 5 is
also in the middle.

Patrick Chanezon, Open Web Advocacy team, Google

There are two aspects to this: Innovation is needed in
the technical community. We could have felt happy that the technical
community invented the ENIAC (the first general purpose electronic
computer), and we could have stayed happy with that. But innovation went on
and look where we’ve reached today. Here we are talking about HTML 5, etc.
So innovation is certainly needed, but standardization is what drives
widespread adoption. If you’re an innovator, as a technical person, you
could be surfing the biggest wave, but if you don’t have that calm sea
behind you that’s brewing up more waves, you won’t get your supplies. It’s
going to be a loud sea, and in a loud sea of innovation, there’s hardly
anything you can eventually end up using. So, standardization picks up the
best of innovation.

Vineet Tyagi, Director Engg, Impetus

Innovation is a pre-cursor to standardization. They’re
not opposing forces, but complimentary. For example, Google was one of the
first companies to try to innovate in offline access. We had a proprietary
product called Google Gears. Then this HTML 5, local storage standard came.
We decided to focus on HTML 5, and we sun setted our own product, Google
Gears. But we had gone ahead before HTML 5 was there.

Rajdeep Dua, Google Developer Relations

Rajdeep was of the opinion that everyone today has a vision toward cloud
Computing, and unless that converges, it would be too early to talk about
standardization at the Cloud Computing level. However, we can talk about cloud
computing standardization at the tools level. For example all APIs Google
supports, say in AppEngine. Even though the underlying datastore is
non-relational, it’s more like key-value pairs, but there is an abstraction
layer, which is standardized. In AppEngine, if you’re developing in Java, you
don’t need to know the low level APIs. You can develop using JDO or JPO. Of
course it’s not 100% supported, within the limitations of what can be done in
Big Tables. “It was a conscious effort that we discourage people to access the
low-level APIs, because application portability becomes an issue”, he said. That
is why instead of coming up with our own server side stack, we used servlets,
JSPs, because we wanted the J2EE spec incorporated in our stack as much as

Mani of OrangeScape seemed very optimistic about standardization because the
underlying concepts for the cloud computing and storage remain the same, just
like how a database has evolved over a period of time. An RDBMS came up with an
underlying concept for database storage, which is distributed storage and
columnar database. You take any database, BigTable, Azure Table storage, they’re
all columnar databases, which is why we’ve abstracted out the layers, and built
all the other layers and made the applications portable on all the platforms.
Now, somebody has to come up with a standard, so it’s only a matter of time till
we get there.

Vineet of Impetus was of the view that while developing products, he would
not want to be driven by maintaining three different versions because there are
three different platforms that need to be supported, each with three versions of
code. The porting efforts in that would be mind-boggling. According to Vineet,
all of this would have to be driven by the quality of service offered by the
Cloud Services provider.

An end user would expect a certain level of standardization so that he could
take his application and deploy it on any platform, whether on JEE or some other
platform. Vineet felt that toward this end at least, they’re excited by the fact
that at least JEE has given them access to the underlying APIs, but at the same
time, he believes that there’s still a lot of work left to be done.

The Author was hosted by Google in Pune.

No Comments so far

Jump into a conversation

No Comments Yet!

You can be the one to start a conversation.