Yet another approach here is download html and Javascript inside the exe and run it locally on the client computer. This permits writing a totally client side application using html and JavaScript.

Ajax is probably a good leading indicator of where web app technology is heading. An application like Gmail has completely done away with the need for a back button, tabs and the like. As more and more developers design their apps to be SSB-friendly, the lack of the elements may cease to be a consideration. Also, there’s absolutely no reason that SSBs can’t have navigation buttons and tabs (like Fluid) where appropriate.

it’s built on Moz, so is certainly not forcing Either / Or (AIR or Prism and Gears extensions?)

it’s got sqllite persistence. it’s got cool media handling. also, you can look at ‘regular pages.’ no taskbar / dock icons per tab. tho that’s doable.

as a technical product guy, i’m a bit mystified by what he audience is asking for here.

@Caltean: I agree that HTA was the first to be directionally correct. There are many approaches to solving this problem, but I suspect the winner will allow the same code-base to be deployed simultaneous across the the desktop and web and eliminate re-work.

Air is cool, and the install process is so easy that it really breaks down the “install hurdle” many other apps face, but Adobe must still let Air apps run seamless within the window to boost adoption rates and bring back the use-anywhere advantage of web-based.

I hope to god (D)HTML isn’t the platform of the future. Using HTML to draw interfaces is itself a hack/workaround–the frigg’n standard was optimized around marking up documents!

So now M$ wants to claim paternal rights about their own abortion?

That’s what I call a lovely father…

IBM did something like that back in 99. And what about Microsoft Active Desktop from 97 ? SSB’s, as you call them, are a byproduct of component oriented software.

Sure, no Flickr integration.. but there was no Flickr. We had modems and pets.com was pure GENIOUS.

Web-to-desktop bridging makes more sense, IMHO, in self-contained widgets that require no true cross-functionality with the browser. This in fact is the motivation behind our own work on bringing web widgets and social network applications out of the browser and into the desktop. A 3rd part of this series touching on the work we’re doing in Hypercube would be great.

A tabbed browser shares the same memory space for all open tabs - leaving the possibility for a browser flaw to have your logged-in bank website on one tab exposed to Joe Schmoe’s exploit code on another.

Also, browser windows/tabs are quite limited functionally by cross-site-scripting and security configurations - for very good reason, but still rule out some otherwise innovative applications. SSB’s have the potential to run protected by themselves and also to allow the user to configure the security settings just for that domain - or otherwise choose the level of trust they want for each SSB application. The SSB just becomes a common container for applications more seemingly integrated with the operating system.

I for one am curious to see where this leads…

Right now I’m using Prism with my legacy web app that includes Flex/Java/HTML components - it makes a compelling combination IF it can be secured and locked from users messing it up and tying themselves in knots.

Many of us have deep/rich existing web apps that we want to extend with technologies like flex and web services - and that seems well suited to a technology like Prism.

Opening new links is a big issue that I guess we’re all still tinkering with. New browser windows, new Bubbles/Prisms/Fluids and new Tabs within the current SSBs are all options. Its true that none of these feel like a ‘right’ solution, so more investigation for all of us.

We see SSB API unison as an important step in the path for a true platform and something that will give consumers happiness (@mark, @todd). I’m pretty sure we’ll soon get around to discuss this. We at Bubbles are making semantic steps towards this in renaming our API namespace to ‘SSB’ rather than prefixing methods with ‘BB_’.

Playing nicely with Gears is also critical in that it will allow us all to wrap up entire Applications. Imagine what it would feel like to use a version of gmail that supports gears, within an easily accessible and supercharged SSB framework, on an airplane for example.

my gmail is in a bubble and it’s an awesome experience, can’t imagine it working otherwise.

Would love to see a live community of script writers to creame more cool “smart bubbles” or whatever they are called.

nice read

So, I could log all of my web visits on the corporate wiki to a internal server for better team awareness, while not having to manage the overhead of turning on and off sharing.

Not sure it’s the right approach, but it is intriguing. Alas, prism has no support for addons right now AFAIK.