Since the advent of the Web, network applications designers have been using HTTP to create a viable Internet applications platform. The relative success of these projects has varied, from the historic missteps of Microsoft's ActiveX, to Sun's incrementally more satisfactory Java, to Macromedia's resplendent - though often unresolved - Flash, to the more hopeful and practical AJAX, to Microsoft's more ambitious - and far more sensible - XAML. But through it all, the general consensus over whether the browser should play an active role has been on again-off again, drifting like a sine wave.

With Adobe's move today to evolve the Flash platform it acquired in the Macromedia takeover, the company is gambling on "off again." Still code-named "Apollo" (its final brand name has yet to be announced), the new Adobe runtime environment was made available to the general public this morning.

As Adobe's senior product manager for Apollo, Mike Downey, explained to BetaNews, "The runtime is a combination of a standalone Flash player - the same player that you have in the Web browser - and we've added additional capabilities to it that are specific to desktop application functionality."

Click here to see screenshots from two working pilot applications built using the new Adobe Apollo platform: eBay's stand-alone auction control monitor, and Finetune's music manager.

Among those additional capabilities are some that will help developers build a complete front-end console, like the one eBay is developing using Apollo, currently code-named "San Dimas" (after the home town of fictitious movie icons "Bill and Ted"). The eBay desktop component could revolutionize its online business by divorcing it from the browser (IE7, Firefox, Safari) without removing its HTML. The result is a stand-alone window that can be operated as a desktop gadget or a full-sized application on demand, where customers can keep continual tabs on designated market segments and the progress of bids they've made.

The HTML engine for Apollo, Downey told us, by the open-source WebKit project, which currently produces the browser engine for Safari.

But is there a central "Apollo language" for this runtime environment? As Downey explained, surprisingly, no. Either HTML or Flash could supply the basic "top-down" structure for an Apollo app, he said. In the case of HTML, functionality would be provided - as expected - by JavaScript (including the asynchronous variety), with style codes supplied by CSS; for Flash, functionality is provided by ActionScript. For the latter, developers may choose to use the Flex development environment originally created by Macromedia for Flash, though it's certainly not required.

Apollo also promises the opportunity to integrate PDF in a functional form, which may conceivably give the portable document standard its first opportunity to present live documents in a hypertext format, competing directly with HTML.

Indeed, there's nothing particular about Apollo that requires any developer to spend so much as an extra cent. The runtime environment will be distributed for free, as Flash already is.

"If you're building an Apollo application," said Downey, "the two biggest things you'll have to learn are: the new APIs that Apollo adds to what the browser and the Flash player can do; and the overall user interaction and user interface design, because you're building more of a desktop app than a browser-based application."

Adobe's hope is to attract developers who have been developing functionality, rather than just content, and entice them to move that functionality off of the browser without significantly altering its form or format.

"The nice thing about using Web technologies to build a desktop app," said Adobe's Downey, "is it's very easy to repurpose those same technologies for deployment to a Web browser, or the opposite direction. So if you've built a Web application that you deliver in the browser today, it's going to be fairly straightforward for you to take that Web application and make it run as a desktop app inside of Apollo, and you would of course then just add additional capabilities, becoming kind of a superset of what you have in the browser."

Next: The case for and against Web development without the browser