SUBSCRIPTIONS
 Computerworld is New Zealand's only specialised information systems fortnightly.
Subscribe now for $97.50 (24 issues) and save more than 60% off the cover price!
NEWSLETTERS
 Get the latest news from Computerworld delivered via email.
Sign up now
NEWSFEED
 Subscribe to Computerworld's
RSS newsfeed here and get news stories as they break.
It's one thing to ask tool builders about their application development vision. It's certainly relevant to contemplate the challenges software developers will face. But if the application platform — in this case, the web browser — doesn't cut it, the computer industry may be in a world of hurt.
Don't assume that toolmakers are perfectly aligned with the browser developers either.
"The people who make a living building web apps and tools for them live on a different planet than the people who build browsers," says Tim Bray, director of web technologies at Sun Microsystems.
Yet, for a happy web development future, browsers have to change.
"Today the browser is a pretty tough execution environment," says Jochen Krause, CEO of Innoopract (the company behind Eclipse RAP). Alex Russell, project lead for the Dojo Toolkit, goes further, saying the browser makers have failed the development community. They've made application design incredibly difficult, he says, because "the majority of browser vendors haven't published a road map, so no one knows what's coming."
Alternatives may be necessary. David Wadhwani, Adobe VP, rich internet application platform, says, "Browsers may hit a wall because of political conflict between browser vendors and their own agendas." As a result, he believes, "developers will depend more on plug-ins to extend the browser."
This raises the question of whether future internet applications will rely on the browser, on plug-ins or on...well, something yet to be invented. And should they?
One possibility is that the border between the operating system and the application will get more and more porous, says David Temkin, Laszlo Systems CTO. Right now, the browser doesn't know when you plug in a digital camera, so — unlike desktop applications that are integrated into their host environment — it can't take action when that event occurs, he says.
"We'll have to see more communication between plug-in vendors and OS vendors," says Temkin.
But the architecture may need some deep navel gazing, he says. The internet (and thus the standards for it) has a heritage of documents; that's not how applications work, Temkin claims. "There's a little bit going on with the browser where it's the tool of choice for delivering network apps; that isn't its heritage, and that's holding it back," says Temkin.
David Intersimone, CodeGear vice president of developer relations, says, "I don't know that I want the browser to be more than just a conduit or a container for stuff. I'm happy if they give us the hooks and APIs to do all these things."
Yet, he contemplates several looming problems for developers, such as how to take advantage of the hardware horsepower on a virtual machine. For example, with computer systems commonly having multiple processors, how does a developer tell a web-based application that one component should use a single CPU? What about 3-D screens, alternate user interface (UI) devices, such as eye tracking or voice? How do users change the way they interact with the interface? If we use a speech UI, wonders Intersimone, do we have to say aloud, "Click it"?
"I am not convinced that the browsers will solve problems for us by adding more capabilities," Intersimone concludes. "I thirst for either a simple browser container with loads of hooks for programmers, or desktop application containers that allow us to bring the internet to the desktop."
Right now, he's exploring what Adobe's FlexBuilder 3 and Adobe Integrated Runtime (AIR) might do; but even it, he says, relies on integration to other programming systems including Java, PHP and Ruby.
It's a good thing that we have web standards; every existing Web 2.0 site relies on them. But some toolmakers worry about the balance between standards and innovation. Russell points out that saying to the browser vendors, "Thou shalt follow the spec" trickles to the browser vendors as, "We shouldn't take risks." Yet, he adds, "The W3C isn't so much wrong as they're downwind." In other words, they don't drive the action.
Still, says Adobe's Wadhwani, the industry has to hold the browser vendors to work toward a meaningful spec and adhere to the spec.
"The spec process is defined by committee," he points out, "so we end up with a really slow, poorly designed environment for creating applications." The situation isn't improved by the fact that vendors all have their own agendas.
"There are those on the inside [of the standards process] trying to scuttle the progress," says Wadhwani. "It isn't consistent with their desire to move the platform forward."
This view is not necessarily universal. Jean Francois Abramatic, CEO of ILOG (who is on the W3C Advisory Board and a past chairman), says, some standards are more to the point than others, but at the the foundation at which developers can talk. The web as a platform for application development wasn't in the cards 10 years ago, so the standards bodies need to reflect new realities, he says.
"I'm not worried here," he says. "Those are the people who are making it happen."
Whatever the politics, the standards committees need to contend with new technologies — and they are indeed addressing new issues. Mobile technologies have been around for a while, so standards work in that regard is already going full speed, says Abramatic. Video is new and work is going on at the moment, but there's plenty more to do.
"There are other areas where we will need to see things happen: in the lower layers of the infrastructure, device independence, content adaptation. There are standards developing," Abramatic says.
|
