As quickly as it came, the hype has died down over Google's announced Chrome OS. There hasn't been much to stoke the fire so it's died down naturally. And that's a good thing. There's a lot of lead time to figure out how we all fit into this story, if we want to fit in at all. Here are a couple of more thoughts that came to me as I read all the stories. BTW, it seems some writers have already played with the OS, or they're making a lot of assumptions...
Equinox as a local app server
One of the coolest features of OSGi and the Equinox/Jetty implementation at Eclipse is as an app server. This is something I've always wanted to spend more time with. I don't think Chrome OS will be successful without some means of running local applications and the marriage between Equinox and the Chrome browser is a natural. I'd hope the two of these groups are talking.
GWT or SWT browser edition?
To be honest, I'm a neophite when it comes to what's happing with running Eclipse in browser mode, be it RAP or the new e4 SWT browser stuff. All I've seen are demos that try to make the browser look like a desktop app. I think that's doomed to failure. The more you make it look like a desktop app, the more users are going to expect it to work the same as a desktop app, and that just isn't going to happen.
I'd take this opportunity to reinvent my application's UI, to break away from the paradigms that the desktop has locked us into and to come up with cleaner, more workflow driven UIs. Having good tooling is still a must. The Google Wave guys were quick to pour praise on GWT which they used to build the Wave app. I'd pick that if I were starting down this road.
Is there a role for native in Chrome OS?
Believe or not, I think the answer is yes. We'll I'm sure you believe that I think that but anyway. Chrome supports the NPAPI native plug-in API that was started by Netscape/Mozilla/Firefox and is now supported by WebKit/Chrome/Safari and Opera. If you have the need for a high performance app that does it's own rendering, like a game say, then NPAPI is for you. Google already does this for it's O3D graphic rendering API. You can too.
Now, what you can also do with NPAPI is present your C++ objects for JavaScript scripting in the browser using this interface. Now didn't Dave Thomas say something about C++ and JavaScript being the future in his Eclipse Summit Europe keynote last year?
ARM versus Intel
It's not a secret that Intel has an offer to purchase my employer, Wind River, on the table. That hasn't closed yet. But I have to agree with the analysts who see this will help ARM and it's partners. More interesting, though, is that this will really be the first time that ARM platforms and Intel platforms will be running the exact same software platform. It'll be pretty easy to see who's netbook/smartbook/mobile solutions are better. More importantly, it'll drive both of them to raise the bar, which at the end of the day benefits the consumer like good healthy competition does.
Have you read Fake Steve's views?
ReplyDeletehttp://fakesteve.blogspot.com/2009/07/lets-all-take-deep-breath-and-get-some.html
Bit of a laugh :-)
Re: wave, I think that Jetty's continuations (http://blogs.webtide.com/gregw/entry/continuations_to_continue) and general asynchronous stuff on the back end bode well, especially combined with the JavaScript comet (http://blogs.webtide.com/gregw/entry/cometd_features_and_extensions) code. It will be interesting to see if that is somehow integrated with Wave, which uses a similar bayeux idea under the covers.
Re: web stuff; did you ever look at bespin (http://labs.mozilla.com/projects/bespin/)? That seemed to demo some kind of things that could be used for a web-based IDE, though I'll confess to having similar skepticism as you. Having said that, there's a lot of cool stuff coming up (sproutcore is the implementation for a lot of Mobile Me stuff) so it's getting better all the time. It wouldn't surprise me if the HTML5/Canvas stuff started to have widgets rendered on the client side, though we're then back to the bad old days of Swing and code-rendered components.
As for will the OS become the web - I do a lot of stuff on the web now (as the ObjectivEClipse change log shows!) but I still think the Apple desktop with its libraries are not likely to go away any time soon.
Mind you, what I currently have open - browser, mail, chat, preview (PDF/images) all could and do get handled by the browser already. The blog-posting software is a nicer text editing widget than I get in the browser, but some of the rich textareas are starting to change that. And adding live preview to a browser shouldn't need to be that hard.
About the only thing I can't replace is Terminal (shell/xterm) sensibly, but more for security than anything else. Oh, and of course, Eclipse :-)
Chrome will be shipping with Google native client allowing you far more control for low level access. Everything has been beautifully laid out for past few years....with GWT being a big piece of the puzzle.
ReplyDeleteGWT for all UI work, Native client then all productivity apps, the groundwork was being done for quite some time.
Ah, yes, I forgot about Native Client, http://code.google.com/p/nativeclient.
ReplyDeleteOriginally x86, I'm sure the ideas can be used with ARM as well. Certainly easier than NPAPI. As long as they give me OpenGL and audio libraries, I'm happy. Still waiting for that on Android.