A new breed of applications: browser-based desktop applications
There is a lot of talks about RIA since there are web application which require richer widgets than HTML. Some approaches are XUL, XAML, Flex,…
However I wonder if there won’t be an opposite trend of browser-based desktop application, i.e. desktop applications which are used from a web browser.
An example which comes to my mind is Google Desktop Search.
The advantage of such applications is that they could enhance user experience by seemingly integrate local manipulation of data with the whole web.
For example, would it be interesting to have a browser-based application which aggregates your weblog entries, google searches, del.icio.us bookmarks and flickr pictures to provide a web dashboard (or more precisely a local web portal)?
You could then be able to drag and drop a google results link in your del.icio.us bookmarks. Or drag and drop a flickr picture in your weblog. Or drag and drop a picture from iPhoto in flickr. Or…
The application could be based on OSGi framework and its embedded servlet container. You have several bundles composed of Servlets for each type of “service” (del.icio.us, blog, flickr) and a dashboard which deals with interactions between the services. Data could be aggregated by REST Web services (either through XmlHttpRequest or HTTP/XML/XSL Java libraries).
Another potential advantage of such an approach is that these local applications could use an intelligent cache (a la Adam Bosworth‘s Project Alchemy except that this cache is not located within the browser…) which will keep the HTTP requests if you’re offline and send them once you are online again.
Does that make sense or is it a crazy stupid thought?
Comments closed
Comments
i agree with you, what make the web work (by the way webwork is a really good MVC more simple and powerfull than struts) is its simplicity. For 2005 the 3 word will be “keep it simple”.
Xul and other aproach won’t work for 2 main reason :
- user are used to their simple web interface and it’s already too complicated for some people ( not all men or woman are IT breed )
- “COST”, i don’t see how you could reduce the development time and its cost with XUL approach
we have today some sort of “GUI” standard in the way we do web application, and more and more we see heavy application converging to this standard.
Even my eclipse looks like a web page
-Top Navigation
-Left Navigation
-Tools to the rights
-Other info on the bottom
The concept of a local web portal is definitely not a crazy stupid thought. To me, it looks like the ideal solution for a thin client OS that provides for content aggregation and local caching. I would start off with Apache Geronimo, add some JSR 168 administration portlets, build a WSRP based framework for integrating remote services, and use JSF, perhaps with support for Struts-Shale, for presenting these portlets. Then you could create a Linux distribution that replaces Gnome/KDE with Mozilla Firefox and end up with a very portable, device independant system.
Scott, I agree with you that a local web portal has some potential. But you seem to want to use if for (web) content aggragation and local caching.
What I mean by browser-based desktop application is slightly different: I want to manipulate and display local data from the web browser.
To give a more concrete example, I made a simple prototype of such an application which can be used to tag local files and aggregate them with del.icio.us bookmarks (like Google Desktop Search can display both local and web search results).
–
jeff
I should have been more precise on what I meant by content aggregation and caching. Web Services for Remote Portlets (WSRP) provides a standard mechanism for content to be aggregated from one portal to another. This aggregation scheme can be extended to a portal running locally on a client device. With such an implementation a portal page that is hosted on this local portal could contain both a local portlet and a remote portlet. Caching could occur at any point in the food chain within the portal hierarchy, even locally where the markup is not being re-generated with each http request. As it is now you can point your browser to a remote (http://) or local (file://) url. What I am describing would enable a user to construct a personalized portal page that embeds both local and remote content side by side. It will get real interesting when there are standard mechanisms for portlet interactions; portlet messaging and data interchange.
My use of the term ‘content’ here would include the notion of an application or applet. Also, a portlet does not have to be rendered in HTML/Javascript. There’s no reason that portlets cannot be presented using Swing, Flash, 3D, etc. It is my hope that complex monolithic applications can be replaced by a more simple paradigm based on compound documents. I had hopes that OpenDoc might have provided such a solution until Steve Jobs killed off the technology. I see standardized portlets as a viable successor to OpenDoc parts.
A sophisticated web based desktop can be found at http://www.oos.cc developed by the iCUBE Network Solutions Team (www.icube.at). Currently filesharing and several applications are supported (file manager, image viewer, text editor, etc)