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...
December 14, 2004
Following my latest blog, I discovered that Firefox handles differently saving a file if you save it as HTML only or as a complete Web page.
If you specify HTML only, it saves the static content of the page (what was loaded at first in the browser). It does not save the DOM of the page.
However, if you specify complete Web Page, it is the DOM of the page which is saved (including generated content of the page). The disadvantage of that approach is that it'll also save the scripts which are used in the file locally in a *_files directory instead of keeping the original URL of the scripts in the HTML file. That means that this page is no longer self-contained and you can't send it to someone else. You also need to keep the *_files close or the JavaScript parts of the page won't work anymore...
What I'd like is to be able to save the DOM of the page but also keep the original URL of scripts. I need to dig into Firefox to see if there are ways to configure its saving behavior...
December 13, 2004
In fact, the prototype CRC Cards Whiteboard (with or without explanations) I made is already usable.
You can play with it, create new CRC cards, delete old ones, etc. The Good Thing is that if you locally save the page (with your browser File -> Save Page As...), the saved file will contain your modifications. You can then point to your local file to update it again. You can also create a new whiteboard by saving it under a different file name..
It was quite a surprise to me. Initially, I thought that the save function of the browser would save the static content of the page while what is saved is actually the DOM of the page even if some parts of the DOM have been generated dynamically.
I'll never stop to be amazed by the power of web browser!