Web-Application Plugins

Because I’m quite busy with university and my job, I don’t have time to create a proof-of-concept of this idea. Instead I’ll describe it in words right now. Many desktop applications offer an API that third parties can use to create plugins for that application. For example Outlook has such an API. Using this API it is possible to add a good spam filter to Outlook, like SpamBayes. For web-applications, however, this is little harder.

Harder? You might say, why is it harder? Many web-applications allow plugins to be written and that works pretty well. That’s true, however, the maintainer of a running instance of the web-application manages those plugins. For example, if I want to install a copy of phpBB with who-knows-what plugin I can do that, but a random user of my forum can’t install plugins. In a relatively small community you can ask the maintainer to install a plugin, but what if the community is slightly larger, say, like Gmail?

Letting random users install software on your server doesn’t like a tempting option, at least it doesn’t to me. So we have to figure out a way to let the plugin run somewhere else and to let it communicate with your web-application remotely. What you’re basically doing here is distributing your web-application’s logic. Now, how would you do that? Ahuh, do you feel it coming? Web services!

Let’s take Gmail as an example. For this to work Gmail would have to offer a plugin API. This API would give access to the user’s e-mail, contacts and labels. A Gmail user would go to Gmail’s plugin page and give the URL of the plugin that he or she wants to use. This URL is the URL of a webservice which conforms to a particular interface. It would, for example, need methods to obtain information about the plugin, such as its name and places where it wants to hook in. The hooks are places where the plugin does something; an example hook could be the displaying of the menu items, you might want to add a new item there, or when receiving/sending an e-mail.

To explain how this will work I’ll take a calendar plugin for Gmail as an example. The calendar plugin adds a new menu item to Gmail’s left menu. When you click it, the right part of the screen will show a calendar view. When you click a date you can see your appointments for that day. How would that work behind the scenes? This interaction diagram might make things clearer:

Interaction diagram of web-application plugin

If you’ve never seen an interaction diagram you should still be able to understand it ;) The left life-line (as it’s called) represents you, the user of Gmail. When you want to go to the calendar you click the calendar menu item. Your browser will send a request for this to the Gmail server. Gmail will know this is a plugin request for the calendar plugin and will call a web service method of calendar plugin web service. The calendar web service will return a resulting (HTML) page, which Gmail on its turn will forward to the user’s browser. A similar path is followed when viewing appointments, adding them etcetera.

You could extend such a calendar by also showing all the e-mail that you sent and received on the day of your appointment, or even allow link e-mail to your appointments. The Gmail web service API would provide you with ways to retrieve e-mail sent on that particular day.

There are three things that you may wonder right now. The first one is: why would you want to add something like this to your web-application? First off, it would turn your application into a developer platform, which puts you in a very powerful position. Secondly, profits from web-applications often come from advertising. The more page views/ad-clicks the more money for you. So, the more time the user spends in your web-application, the better for you. If third parties want to add features to your web-application that makes it more attractive to your users, why wouldn’t you support that?

The second thing that you may wonder about is security. This is an issue that needs to be figured out. I’m pretty sure it’s possible to secure this properly, though.

The third thing is performance. With all this web-service calling behind the scenes, what will the performance be like? I don’t know. You can only find out by trying. That’s also the reason why I wanted to create a simple proof-of-concept system, but I have yet to do that. Some kind of caching on certain places may be needed to keep things responsive.