Joshua Marinacci's Blog

Unleash the MiniApp

It's gonna be a busy week so I'll keep this short. I've been thinking a lot about moveable applications and the idea of rich clients. This is mainly on my mind because the Flying Saucer team has been hard at work on the next version of XHTMLRenderer. (We're shooting for an August 31st release) An embedded rendering component has pretty much one core use: applications with both GUI and html interfaces. But what do they look like? What creatures live in that shadowy borderland between the desktop and the web?

The obvious example is the iTunes Music store. Having an HTMLish component lets Apple embed visually rich content which can change without requiring a software update. But iTunes still has as a desktop interface that satisfies the core function, playing and organizing music, better than a purely webbased program ever could. But this is old news. What else is out there? And why don't I have them?

I think that we should have a Konfabulator / Dashboard equivalent in Java. They each approach the same idea, small easy to write/install/use applications, from different sides. Konfabulator starts with a desktop program and adds internet dynamic content (like rss feeds and webservices), then makes it pretty with web-era graphics and animation. Dashboard starts with pretty webpages and pulls them out of the webbrowser into separately launchable programs with more local control than HTML and Javascript typically allow. I'd like to see us do something like this in Java.

I want to be able to hit Ctrl-Alt-F2 to get my RSS headlines to popup. F3 gives me my MP3 player and F4 for an internet wide Online Help search. (With first priority for JavaDocs of course). F5 would be a MiniApp implementation of Frink, the coolest calculator I have ever seen. (It performs conversions between any unit, letting you definitively calculate the density of the alien mothership from Independence Day). These are MiniApps (TM) I want to see.

Imagine a constantly running program that manages MiniApps. It could be visualized as a dock, taskbar, or sliding Expose' sheet. Or maybe all three! Every program implements a simple common API, say a subclass of org.javadesktop.MiniApp. The MiniApps would run in a sandbox similar to WebStart apps or Applets with crossplatform APIs for user alerts, preferences, and webservice access. Since everything runs inside the same JVM (with the appropriate safety mechanisms), we could avoid the 25MB hit that each separate Swing instance and runtime.

Every MiniApp has the ability to access web resources but runs locally, even when disconnected. Think of it as the best of Gnome Panel applets combined with server based web programs.

Here's a few more ideas for MiniApps:

• Local Weather, Movie, and Traffic Listings with alerts, like an accident that's going to block my exit on 285 for the next four hours!
• SuperRef: search through the dictionary, thesaurus, and quotation index to make my articles appear smarter than they actually ar.
• MiniCal: which ties to Outlook/iCal and alerts when it's time for lunch.
• MiniSheet: for quick calculations. Is there enough in my bank account to buy that new SouthPark DVD?
• MiniDraw: annotate the current screen with a precise description of why feature X doesn't match the documentation, automatically CCed to the developer list
• InstaFlame. Lets me compose short blog entries as the ideas arrive and post immediately to my blog without starting up new software or having to reconsider my ill-conceived opinion.
• eBayLert. Tell me when I'm about to be scooped on that valuable 1961 vintage Jetson's Lunchbox.
• SafariSearch. Let me search through books and documentation in my current Safari subscription. I want to know the syntax of JComponent.repaint() and I want to know now!

And of course the best thing about MiniApps is that they would be written in 100% Java, letting the minis run on any platform without fear of malware or viruses

Comments

• Sounds like fun
  I might be fun to implement something like this. I would consider using Thinlet instead of Swing for the UI.

  Posted by: bensinc on August 24, 2004 at 07:20 AM

• Sharing should be a choice

  "Since everything runs inside the same JVM (with the appropriate safety mechanisms), we could avoid the 25MB hit that each separate Swing instance and runtime."

  
  There are no appropriate safety mechanisms. If you can show otherwise, that deserves a project in its own right. I'm convinced that it could be done using a combination of SecurityManagers and ClassLoaders that perform bytecode manipulation, but that is largely speculation on my part.

  Any platform that allows multiple applets/miniapps to be run within the same JVM should also allow them to run in different JVMs. Spawning your own JVM is a pain, but much better than having a single bad player nuke the game. I hope isolates make it into Mustang. Then again, they were overdue long before Tiger.
  

  Posted by: coxcu on August 24, 2004 at 07:30 AM

• Sharing should be a choice
  If I were to implement this, protecting "MiniApps" from each other wouldn't be a high priority, at least not at first.

  If you install a MiniApp that misbehaves, just stop using it and ask the author to fix it. Nobody would force you to install poorly written MiniApps.

  Posted by: bensinc on August 24, 2004 at 07:38 AM

• Same VM?
  At JavaOne Sun said they were hoping to have the JVM be a daemon service instead of a new process every time. Given that, should we focus on getting the apps built and started easily instead of running out of the same VM? Or should we not count on a release two years out?

  Dave

  Posted by: dwalend on August 24, 2004 at 07:48 AM

• Sharing should be a choice
  I agree. We have the technology to build in such safety, but I don't think anyone has thought through the social side of such a system.

  In my ideal world you would get very restrictive default permissions for anything you download off the web. If a MiniApp needs more access it would have to ask you, but only at the time that it actually needs it, not at the time of installation. By default apps would get preferences storage and some scratch disk space (possibly virtual) to use, so it would only need to ask for more when it really needed it.

  There would also be a manager app that could configure, deactivate, and uninstall any mini-app. It would even have a safe mode, so if a miniapp just starts going crazy and crashing the system every time, then the manager app (running in another JVM probably) could shut it down and take care of cleaning up.

  This is essentially Java Web Start with a lot of usability changes.

  Posted by: joshy on August 24, 2004 at 10:11 AM

• Sounds like fun
  I would make it require a JComponent at the lowest level but nothing would restrict you to using the rest of Swing. As long as you used something that ran on top of JComponents (as I believe Thinlet does) then you'd be fine. Just like Servlet this should be a minimal API.

  - Joshua

  Posted by: joshy on August 24, 2004 at 10:12 AM

• Same VM?
  I think we could design a simple API that allows for the existence of a complicated JVM sharing/pooling scheme without actually requiring one. Ideally the MiniApp would be as isolated from the system as a Servlet is.

  - Joshua

  Posted by: joshy on August 24, 2004 at 10:14 AM

• rich client
  So you are interrested in rich clients?
  I am working on an open source project.
  We have a plugin engine which uses some ideas of the eclipse one (extensions and extension points).

  Currently we have a pre release of M1 of the plugin engine availible for download, its very small but still very capable, it can use different xml parser for the configuration files of plugins, are smallest version use a xml parser from the jdk (1.4+) and is only 27 kb in size.

  It can load from a directory and from a plugin archive, these plugin archives can contain embeded jar/zip files. Class files from the embeded jar/zip files can be loaded at runtime without extracting to disk.

  It will support dynamic loading of plugins, currently it can load new plugins without restarting the application, unloading and reloading of plugins are not fully working yet.

  We are also working on a Swing UI framework (appshell) that is build around the engine.
  This is not availible for download, but you can get it via cvs.

  We also are working on a swing component lib which includes a wizard, filechooser and some other components.

  Our project site is http://sourceforge.net/projects/genpluginengine.

  Posted by: carmello on August 24, 2004 at 12:04 PM

• rich client
  Very interesting. If I understand your website this is a framework for packaging and loading plugin modules for any type of application. Could this support security along with location independence? For example, could the plugin.xml specify what features are requested? And could the plugin container enforce security constraints, potentially spinning the plugin off into it's own JVM if desired?

  - Joshua

  Posted by: joshy on August 24, 2004 at 12:14 PM

• Of docksand applets...
  I am developing an application called TKAppletBar. Its goal is to mimic those desktop sidebars that are being developed frequently these days in response to Microsofts idea of a sidebar as found in very early Longhorn previews. It however extendeds this idea by having two views, one docked view and one that allows to display modules in an individual, movable and resizable window.

  What I do not see, however, is the need to develop still another protocol or plugin mechanism. I decided to use applets - plain, "old" :-) widely available applets. Tough I have still a lot of work to do, an early preview will be available soon.

  Posted by: tommi_kuenneth on August 24, 2004 at 11:18 PM

• Of docksand applets...
  I don't know if the Applet API provides exactly the security we would want, but it's certainly a good start. So you are running Applets inside of your sidebar program? How do you install/launch them? What kinds of programs do you have so far?

  thanks,
  - Joshua

  Posted by: joshy on August 25, 2004 at 07:26 AM

• Of docksand applets...
  Joshua,

  the applets indeed run inside the sidebar. The width of them is fixed (determined through the width of the bar itself), the height is determined from the html file that (usually) accompanies the applet. This applies if they are in docked mode. You may, however, undock them, which means that they run inside their own movable and resizable window. If all applets are undocked the screen probably resembles Dashboard(Konfabulator (well, the window decorations should not be there :-))

  To "install" an applet you simply open the html file. At the moment this is done through an entry in a popup menu, but I will include d&d support so that one can install applets by dragging their html file onto the sidebar.

  Most of the demo applets part of the J2SDK already run. I plan to maintain a list of third party applets that run inside the bar

  I hope to be able to provide a preview very soon.

  Regards
  Thomas

  Posted by: tommi_kuenneth on August 25, 2004 at 10:09 AM

• rich client
  There are 3 pieces to the goal of our projects. A small plugin engine that manages plugin modules, so that you can modularize your code into smaller pieces that are deployable at runtime (reloadable) but can still depend and make use of other dynamically loadable modules.

  The second piece is to deliver a Swing based application framework that makes developing Swing apps much easier. Not with a GUI drag/drop tool, but instead by providing a library of plugins to deploy with your app. For example, an email plugin, ftp plugin, jms plugin, web services plugin, etc that all provide a means for other plugins to make use of them so that they no longer have to provide the same redundant and often similar code that is usually written over and over. We'll provide the appshell framework built up entirely of plugins. The UI that is there now is made up of a few plugins, such as the preferences dialog, the core UI for adding menu items and toolbar buttons, and so on.

  The last part is a library of components, mostly UI, that make it easier to develop rich UIs. The JFileChooser is a sore topic for many, has many issues although 1.4 and now 1.5 have made improvements. We are adding at least one, if not two different choosers to use, including one that can block access to folders that shouldn't be accessible. Other components are those that may provide a more visually nice UI, such as rounded panels with title/information areas at the top (for icons and information indicating what goes in the panel below it), shadowed panels, etc.

  As for its use. As I see it if you can write java code in a normal application to do what you want, you can use the plugin engine to make it pluggable. For example, you can deploy an app on a beta that has no security. Then, you write the security code into another plugin and deploy it without having to repackage the entire application. Other plugins will make use of that security plugin as necessary.

  As for location independence, I have two plugins I am working on now. One is an auto-updating plugin. You set any number of URL locations and it will poll those areas for plugins. If found, it compares them to any that are local. If they are newer (and eventually version info will have a role in this as well), it will download the plugin (via the plugin archive file) to the local system, then reload the plugin. The second is a "server" plugin that right now simply listens on a port for tcpip info. Using Telnet, you can connect to the plugin engine via this plugin, and I provide a very rudimentary set of commands. You can basically send info to the server plugin to get a list of all plugins including their status, start/stop/load/unload a plugin, etc. Nothing fancy, but good enough that a remote client could be written (and one is in the plan) to monitor and control the plugin engine remotely, hence an IT team could make good use of this if an application they wish to monitor/control.

  Please, join the mail list and ask some questions. We'd love to better the course of the project. The engine is just about in M1 release, but the appshell framework could use help building plugins that others will find useful. The great thing about the appshell is you are not stuck using all the plugins. You can make your own build process and use only the plugins you want. All plugins are loaded as they are used. If plugin A depends on B, even if A is running, B is never running until A uses it (or some other plugin)..

  But please join up. We'd love to have help! It's all open source, BSD license, use it as you wish. We only ask anyone helping to contribute back to the project so others can benefit.
  

  Posted by: buckman1 on August 25, 2004 at 01:11 PM

• rich client
  you can use our framework for any type of application, for gui or command line based applications, everything is posible except for J2ME based application becourse ME doesn't support custom classloaders.
  Maybe we create a ME version in the future but it will not support dynamic unloading and reloading of plugins becourse of the absence of custom classloaders support.

  > could the plugin.xml specify what features are
  > requested?

  in the plugin.xml file you can have depencies, for example a plugin can provide e-mail features and another plugin can specify a depency on the other plugin and use it.

  > And could the plugin container enforce security
  > constraints, potentially spinning the plugin off
  > into it's own JVM if desired?

  Plugins are running on the same plugins. All plugins have there own PluginClassLoader so a plugin may not see all other plugins. A plugin can contain classes that are not visible to other plugins, a class with .internal in his package name is only visible to the plugin were its part of.

  If you (or/and others) have more questions,comments or feature requests you can send it to our mailing lists on http://sourceforge.net/projects/genpluginengine.

  Posted by: carmello on August 25, 2004 at 02:34 PM

• Of docksand applets...
  This all sounds pretty nifty. Could you send me a link when you have a page up and a release I can try out? I'm starting to think along the lines of a unified interface for mini apps, that way they could be hosted in any sort of environment from any vendor (docks, applets, expose screens, stand-alone, etc).

  - Joshua

  Posted by: joshy on September 13, 2004 at 08:59 AM

This work is licensed under a Creative Commons License.