January 7, 2005
Following my last post on browser-based desktop applications, I prototyped a little application to play with these ideas.
I'm a big fan of the social bookmarks manager del.icio.us which enable you to bookmark urls and categorize them. However, all your bookmarks are available to everyone else (it manages social bookmarks after all). But, from time to time, I also need to bookmark urls that I don't want to share (e.g. private ones or professional ones which could give too much hints to competitors).
So I bookmark these URLs with my browser. But they can not be categorized like del.icio.us ones (folders don't help). So when I want to check bookmarks for a given topic I've to look in two different places and interfaces (the web bookmarks toolbar and del.icio.us).
I prototyped a simple application with the following requirements:
keep a private list of bookmarks
categorize them like in del.icio.us
aggregate private and del.icio.us bookmarks
display them in the same interface
search categories for both private and del.icio.us bookmarks
The prototype is a browser-based desktop application (i.e. a standalone application which runs its embedded HTTP server and is displayed in the browser).
The application keeps a list of private bookmarks and aggregates them with del.icio.us ones (retrieved with del.icio.us REST API thanks to the delicious-java library). In fact, from the user interface, it is quite similar to del.icio.us interface. The only differences is that private bookmarks are automatically categorized with a private tag. (As an aside, I first had two type of bookmarks: public and private ones. But as I coded, I realized that I could used the bookmark own tags to categorize them as public or private...).
Special urls (like for displaying bookmarks for a set of categories) redirect to the application which filters both del.icio.us and private bookmarks.
Here some screenshots (I haven't care much for the layout but it is based on del.icio.us):
To save a bookmark, type its url, its description, its (optional) extended description and list of space-separated tags. To save it in the application ( i.e. on your desktop), tag it as private. Otherwise, the bookmark will be saved on del.icio.us.
If I look for all the bookmarks with the osgi tags, I see that some of them are categorized as private. They're stored on the application and not on del.icio.us (see my del.icio.us OSGi page to see the differences).
As you can see on the screenshots, the only differences is that private bookmarks are categorized with a private tag.
I haven't reproduced all features provided by del.icio.us but this first prototype is functional enough to help me vizualize what browser-based desktop applications could be.
I see this prototype like the equivalent of Google Desktop Search but for bookmarks. Both application aggregates local and web data and displays them in a consistent way in the browser.
As for the technology I used, it's based on the OSGi framework and its HTTP service (I used Knoplferfish implementation). The cool thing is that everything can be delivered as a standalone application that sits anywhere on your hard drive. You just start it and point your web browser to http://localhost:8080:. It's also possible make it a Windows or Mac OS X service with a cute little icon in the tray.
And, being based on OSGI, you can also use it from your PocketPC!
One other cool feature of this application is that since it sits on your own machine, you can also bookmark local files and categorize them.
For example, I've a local version of the OSGi specification in PDF file. I bookmarked it with my application with the url file:///Users/jeff/doc/...../r3.book.pdf. So when I want to see all my bookmarks related to OSGi (http://localhost:8080/jmesnil?tag=osgi), I've got both web url and local documentation (URLs starting with file:// are automatically tagged as private and local).
The only problem is that you can't open the files from their URLs (I already blogged about it but I haven't find a correct solution yet).
There is nothing rocket science in this prototype but there is some potential for such browser-based desktop applications to integrate in a consistent way desktop data with the whole web.
January 7, 2005
I have got a stupid problem: I have a HTTP server on localhost which serve web pages containing links to file:// URLs.
Firefox refused to open these URLs (which is completely understandable to avoid security holes). In fact, you can't load them by clicking on the link but you can load them by dragging the URL to Firefox address bar.
If I want to load them by click, I can bypass Firefox security by setting security.checkloaduri property to false (in about:config preferences page). However it will also expose this security hole to any HTTP server which is clearly not acceptable. What I'd like is that Firefox accepts to load file:// URL from http://localhost only but not from any other HTTP server.
I can't find documentation to enable this... I need to look for another solution to this problem...
January 5, 2005
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?
January 4, 2005
What I said in my last entry concerning OSGi and Component Versioning is not accurate (not to say completely wrong).
I wrote that:
With OSGi, you can state the version of the bundle you want to import. It also takes into account compatible versions. Since bundles have their own classloaders, you can have different bundles using different versions of the same library without conflict.
To check that, I wrote some bundles and it does not work that way.
As is stated in OSGi specification:
A bundle may offer to export all the classes and resources in a package by specifying the package names in the Export-Package header in its manifest. For each package offered for export, the Framework must choose one bundle that will be the provider of the classes and resources in that package to all bundles which import that package, or other bundles which offer to export the same package.
and
If more than one bundle declares the same package in its Export-Package manifest header, the Framework controls the selection of the exporting bundle. The Framework must select for export the bundle offering the highest version of the declared package.
If I read it correctly, that means that you can only have one version of a given exported package identified by the highest specification-version value.
So OSGi won't help to solve runtime dependencies nightmare experienced by anyone using different projects, each one depending on different versions of Jakarta commons jars...
So next time, I'll first RTBS, then write some code and finally blog about it instead of blogging first...
P.S.: OSGi versioning is based on Java Product Versioning Specification which is worth reading...
January 4, 2005
The tsunami in Asia is a tragedy. It became even more so when I learnt that someone I knew and his family were among the victims.
Denis Caromel is an ObjectWeb fellow. I had the pleasure to meet him and talk to him at several ObjectWeb meetings and he is a really nice guy.
He and his family were in holidays in Sri Lanka when the tsunami occurred. He is safe in an hospital but his wife and their two children are still missing.
I feel so helpless and there is nothing I can do to help him but raise attention to this link where you can find pictures of his wife and children and a map of their location in Sri Lanka.
January 3, 2005
I saw this thread of Java.net community forums about missing features to administrate libraries in Java.
OSGi helps with two shortcomings of the Java platform (not Java language):
- Component Versioning
- Published Interfaces
Component Versioning
There is already a notion of versioning in Jar specification. But I'm not aware of simple tools to take advantage of it (a.k.a "write you own ClassLoader").
With OSGi, you can state the version of the bundle you want to import. It also takes into account compatible versions. Since bundles have their own classloaders, you can have different bundles using different versions of the same library without conflict.
Published Interfaces
Another useful feature of OSGi bundles is the idea of published API (see Martin Fowler's article "Public versus Published Interfaces" for a definition of published interface).
You have to state in the manifest of your bundle the packages of the other bundles you're depending on. Your bundle can then only load classes from these packages and not from any other packages.
Eclipse plug-ins makes the distinction by putting their published interfaces in org.eclipse._foo_ package and the public API in org.eclipse._foo_.**internal**.
It is not recommended to make your plug-in dependant of internal packages but you still have the freedom to do so at your own risk if you really need it (e.g. to circumvent a bug or to extend the plug-in if it does not expose a feature as an extension point).
I really like the idea to make an explicit distinction between the public interfaces of a component and the published ones.
These days, thanks to autocompletion in the IDEs you can inadvertantly import and use a part of a component which is not meant to be used by its clients.
With OSGi, you can't use a package if it's not explicitely stated in the import-package header of its manifest file. Of course, you can still import internal packages but it has to be done explicitely in the manifest file. The advantage of OSGi is that with a quick look at the manifest file, you can see the boundaries of your bundle:
- what it depends on
- what it provides (at package level)
While with "standard" jars, it is more difficult to see all its dependencies in one look.
Since Eclipse 3.0, OSGi framework has been under my radar but I hadn't had the opportunity to develop an application based on it. I'm not aware of Open Source applications based on top of OSGi (other than Eclipse) but I think there is a lot of potential to develop an application on top of it. Not only for the two features I described but for a lot of other reasons (hot deployment, remote administration).
Another cool example is that application help could be written in HTML and available as a Bundle taking advantage of OSGi embedded web container (e.g. like Eclipse Help). That way, you have simple to write documentation without the need to keep all the versions of the documentation of the available versions of your application on your web site.
December 30, 2004
2004 has been like every other year: with a lot of ups and downs.
What made it different from the other years is that there have been few ups (which were not very high) and way too much downs (which were really deep). Some of what I built for the last few years has fallen apart and I need to start anew.
So, with this new year, I hope it'll be better and I'll do what is needed to ensure that.
I've made some resolutions for 2005. With these in mind, I expect 2005 to be a very interesting and motivating year if not a happy one.
Anyway, happy new year to everyone!
Finally, my thought goes to the victims of the tsunami and their families. I've made a donation as everyone else and it's reconforting to see such worldwide help. In this time of war, fear and distrust, this is a hopeful sign of friendship and humanity between people, no matter their colors, religions or cultures. It's a good feeling to end a year and start a new one.
December 28, 2004
At last, we get some snow here at Grenoble
Now, it really feels like christmas time...
December 23, 2004
I'm currently playing with OSGi. There are two Open Source implementations (Oscar and Knoplerfish) you can use.
Another Open Source OSGi framework is provided by Eclipse since its 3.0 release.
To launch its OSGi framework without starting all Eclipse:
- put in your classpath all the jars in
$ECLIPSE_HOME/plugins/org.eclipse.osgi_3.1.0/ start the framework with
java -classpath $CLASSPATH \ -Dosgi.framework="file://$ECLIPSE_HOME/plugins/org.eclipse.osgi_3.1.0" \
org.eclipse.osgi.framework.launcher.Launcher -console
You then have the framework started:
osgi> status
Framework is shutdown.
id Bundle Location
State Bundle File Name
0 System Bundle
STARTING org.eclipse.osgi.framework.adaptor.core.SystemBundleData@17f1ba3
Registered Services
{org.eclipse.osgi.framework.console.CommandProvider}=
{service.ranking=2147483647, service.id=1}
osgi> launch
osgi> ss
Framework is launched.
id Type State Bundle
0 ACTIVE System Bundle [0]
osgi>
It is then ready to install and start new bundles (e.g. available from Oscar Bundle Repository):
osgi> install http://oscar-osgi.sf.net/repo/log/log.jar
Bundle id is 2
osgi> start 2
osgi> status
Framework is launched.
id Bundle Location
State Bundle File Name
0 System Bundle
ACTIVE org.eclipse.osgi.framework.adaptor.core.SystemBundleData@17f1ba3
2 http://oscar-osgi.sf.net/repo/log/log.jar
ACTIVE http://oscar-osgi.sf.net/repo/log/log.jar
Registered Services
{org.eclipse.osgi.framework.console.CommandProvider}=
{service.ranking=2147483647, service.id=1}
{org.osgi.service.packageadmin.PackageAdmin}=
{service.ranking=2147483647, service.id=2, service.vendor=Eclipse.org,
service.pid=0.org.eclipse.osgi.framework.internal.core.PackageAdminImpl}
{org.osgi.service.startlevel.StartLevel}=
{service.ranking=2147483647, service.id=3, service.vendor=Eclipse.org,
service.pid=0.org.eclipse.osgi.framework.internal.core.StartLevelManager}
{org.osgi.service.log.LogService}=
{service.id=4}
{org.osgi.service.log.LogReaderService}=
{service.id=5}
osgi>
December 23, 2004
Last day of work before Christmas, so Merry Christmas to everyone!
On a personal note, I hope Santa Claus will bring me Java 5.0 on Mac OS X saturday night...
