Implementing Plugins

It was obvious to us from the beginning that we would need to provide way to incorporate other peoples’ ideas and solutions into TMPortal. We needed to make space for plugins that other parties (suppliers) could develop and offer. This would enrich the power of TMPortal and give users a variety of content sources. We understood that our success would be measured by the level of integration of the web community in our project.

So, the plugins were a must, but how to implement them? They would represent program code that a user could download from the plugin store and install on their website. It would be foreign code running on their webserver. This, by definition doesn’t look safe. If misused, it could potentially make havoc on the users’ system.

We had two problems to solve: how to allow programs to be installed and run on the webserver and how to protect the server from malicious code and its ability to damage it.

There were various ideas, like allowing third parties to upload a DLLs with all their code into a Bin folder, to import the source code in an App-Code folder in Microsoft Visual Studio where the code is interpreted without the need for compilation, to execute in a sandbox environment, to work within iframes, etc. It was difficult to find the proper balance between allowing plugins enough freedom and power to provide their functionality and at the same time restricting them to prevent misuse.

A solution we came up with offered the simplest way to resolve both of these problems. We decided on the following:

There won’t be any server-side processing of the plugin code on the user’s systems. All such processing will be done on the supplier’s system (where it belongs anyway). They would develop web services to provide channels to communicate and distribute their content. The fact is that most of them already had web services developed for that reason.

On TMPortal, all the suppliers have to do is to develop our standard Components (HTML, JavaScript and CSS) that would be added to web pages. The components will use AJAX to communicate with the web services to initiate processing there and bring contents to the browser. The components will display the content on webpages always in the same way regardless whether they come  from a remote suppliers or our systems.

In that way, both sides would do the job where it belongs: the plugins would be processed on the supplier’s webserver without any restriction that we would otherwise have to enforce on them, and on our side, a simple component would be responsible to bring the content to the web page without fear of misuse.

Our idea with plugins was from the beginning that they would be free to download and install. This meant that plugins provided by suppliers had to be free as well. This concept had one flaw: we had to figure out how to motivate suppliers to offer their content via free plugins. There had to be some way for them to charge for their content if they wanted.

The solution was unexpectedly easy. The suppliers could offer two ways to provide the content. One was to provide free content but include ads in it. The other was to request users to login and subscribe to their websites and potentially pay fees. They would get some identification keys to put in the plugin component that would provide access to the supplier’s content. 

So, the plugins would be free, but the content that they display may not be and would depend on suppliers. This is nothing unusual and is the normal way the web operates. It also simplifies the supplier’s job: they probably already have web services developed. All they have to do is to make a component that will use the services and bring the content to browsers.

The last thing to figure out and implement for us was to provide a Plugin Store, a place for users to search for existing plugins, download and install them, and also for suppliers to offer their plugin to others. We use the word Store as it is commonly used through the web to offer plugin to others. This name is in a way misleading as Store implies that we are selling something. There is no payment system implemented in our Store as components are free to download. The work Library might be closer to the real essence of it.

The plugins (and in general all our components) are built using HTML, JavaScript and CSS. They are offered in source code so that user can copy, modify and adjust to their needs.

To prove the concept, we made a first plugin that brings content from another website. This shows how it all works and allows us to document it as an example. As the first plugin we have chosen to bring data from our other website www.funside.net where we have several simple games and puzzles. We have a Buzz Words ‘game’ there. It creates texts of certain types (like love letter, political speech etc). The text is generated from buzzwords: it doesn’t mean anything but looks convincing. We made two web services on the FunSide website and then created a simple component to bring the generated text to the TMPortal screen. You can find out more about this in a KB article.  It explains how this works and gives examples for how to develop and implement a plugin that displays data from another website.