Geertjan is a DZone Zone Leader and has posted 468 posts at DZone. You can read more from them at their website. View Full User Profile

A Usable & Secure Mechanism for Plugins in the Lobo Browser

  • submit to reddit
One excellent side effect of Lobo's Java Web Browser being a pure Java application is the fact that it can acquire its infrastructure from a pure Java application framework. And, apparently, that's exactly what it needs, because Jose, its project lead, wrote the following at the end of my recent article How to Add Syntax Coloring for XML in the Lobo Java Web Browser: "I think an important next step in the project is to come up with a more usable and secure mechanism to install plugins." In this article, I look at how to achieve that and show preliminary results.

The Lobo Java web browser is perfectly positioned for migration to the NetBeans Platform. I can say this with confidence for the following reasons:

  • It needs an infrastructural basis. Clearly, from Jose's statement quoted above, the browser has developed to such an extent that the lack of certain common infrastructural paradigms is becoming a significant problem. The "usable and secure mechanism to install plugins" is the one most clearly felt, but points to other similar issues. For example, if you're missing a plugin mechanism, you could also be battling with other infrastructural concerns, such as a windowing system and a persistence methodology.

    Indeed, from studying the code, there seems to be a lot of code dealing with persistence. I believe the caching mechanism, which seems to be spread in a variety of places throughout the application, must be quite difficult to maintain. Similarly, the browser comes with a number of different types of windows and I wonder whether these are all necessary, in light of the various windowing systems that are currently available (e.g., JDoggy and so on). But, the NetBeans Platform provides all of the above at the same time, so seems appropriate since so many infrastructural concerns are applicable in this case.

  • It is pure Java. The ui toolkit used by this browser is Swing. That's wonderful because it means that the ui doesn't need to be rewritten, in order to be moved to the NetBeans Platform, which is also Swing-based. It "only" needs to be migrated. Not just that, but someone who understands the code behind this browser is going to find it relatively easy to transfer the relevant parts to the NetBeans Platform, since the ui toolkit is the same.
  • It is modular already. In yesterday's article I showed how to set up the browser as a normal Java application. In that context, this is how the project outline looks:

    Once it is moved to the NetBeans Platform, here's the project structure again. Note how similar it is (I only added the Substance look and feel, as a new module):

    The modular structure of the original application lends itself very well to the modular architecture of the NetBeans Platform. In fact, in most cases I simply copied and pasted the packages from the original modules into the new modules.

Now, this is how the official Lobo browser currently looks, i.e., when you download it from the Lobo site and run the JAR file:

And, though I haven't got the connection working correctly yet (hence the error message), and have disabled several parts of the application temporarily (such as the security manager and the caching mechanism), this is how it currently looks on the NetBeans Platform:

Above, I have selected the Plugins menu item. That's the usable and secure mechanism for installing plugins that I referred to earlier. (One distributes plugins by putting them on a server, describing them in an XML file that is also on a server, and then telling one's users to register that XML file in the Plugins Manager, which is accessed from the Plugins menu item above. Then the application accesses the server that provides the plugins, as described in the XML file.) However, the architecture of the Lobo plugins would need to be looked at in light of the structure of NetBeans modules. They are not the same and quite possibly the structure of Lobo plugins would need to be changed considerably to make them conform to the requirements of the NetBeans Platform. On the other hand, the application above can now, already, benefit from MANY plugins that have been made for the NetBeans Platform.

There is a lot left to be done. The above is a first step and I have already learned a lot from it. Hoping to get further with it, which would mainly involve getting the connection to work and then moving the menu item code into the menu items that you see above. But, most importantly, I need to look at how to restructure the Lobo plugins in such a way that they're NetBeans modules. The clientlets, for example, need to be installed as NetBeans modules rather than JARs in the distro's ext folder.

Published at DZone with permission of its author, Geertjan Wielenga.


The Lobo Project replied on Sun, 2008/02/10 - 10:02pm

There are other models, like the Eclipse model :)

There's OSGi as a potential framework, which is very well thought out and complete. (Apache licensed reference implementation.)

The end result I'm looking for is a format to publish plugins on the web. It could be a XML file, or it could simply be the plugin JAR file itself. The idea is that you just click it and installation is taken care of. Additionally, it needs to check for JAR signatures. The user needs to be told if the signature is trusted, and warned that plugins have pretty much full permissions.

Automatic updates can come later. I'm reminded of a recent security bug in FireFox, having to do with automatic non-secure updates.


Geertjan Wielenga replied on Mon, 2008/02/11 - 2:15am

Sure, OSGi is a solution too. But, by the way, all of this that you need is supplied by the NetBeans Platform approach as well, exactly as you describe it: "The end result I'm looking for is a format to publish plugins on the web. It could be a XML file, or it could simply be the plugin JAR file itself. The idea is that you just click it and installation is taken care of. Additionally, it needs to check for JAR signatures. The user needs to be told if the signature is trusted, and warned that plugins have pretty much full permissions."

James Imber replied on Mon, 2008/02/11 - 5:54am

I've been to the Lobo/Cobra website and I miss something very important: an exhaustive compatibility list.

If Lobo is first and foremost a web browser, the web developer would like to know if its webpage will render well on that browser. At a minimum there should be a list that states element by element, attribute by attribute what is implemented and what's not implemented.

However, in the web browser world, to implement something is not enough. It has to be implemented well. What is "well" for a little browser like Lobo that has an insignificant market share? It means to implement it the same way Mozilla (or IE) does. The world doesn't need another browser than renders things differently.

The Lobo Project replied on Mon, 2008/02/11 - 9:17am

Yes, the Netbeans Platform sounds like a good idea. I'll plan to read up on it, and evaluate how well it can be integrated and redistributed.

For James, yes, when trying to determine the low-level details of how some part of HTML should behave in Lobo, I look at IE and FireFox. Sometimes they do things differently from one another, and when that happens, I go with what makes sense, which more often than not turns out to be the FireFox behavior.

Eventually there might be an exhaustive list of supported and unsupported features. For now, you basically need to give it a try, look at the source code or ask me. There are some bug reports that mention missing pieces, and some high level info in the browser page.

The next version is going to be 0.98. This means there are probably 5 to 10 more releases before 1.0, which I expect to happen in Q1 2009. Lobo certainly doesn't have many users right now, but I'm happy with its growth, which currently is around 150% a year. I hope that is maintained or improved.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.