Tool installers

First, it's optional, not required. The OPML Editor can and will install tools that don't one.

It's a top-level table, at the same level in the object database as the Data, Info, NodeTypes, Responder, RpcHandlers, SoapHandlers, Suite, Thread, Website and WindowTypes tables.

It contains one or more sub-items with fixed required names, some booleans, outlines, scripts, sub-tables, etc. All are used either in installing the Tool or uninstalling it.

It's partially for efficiency, otherwise code would have to be added in the init script that checks every minute to see if something exists. With the #installer approach, the tool doesn't have to implement any code to install things, and it only is overhead at install-time. One less thing to worry about, and less CPU usage.

But mostly it's designed for maintainability, and to elevate the process of developing a tool. Why should you have to worry about the same set of problems every time you write a tool. Lack of uniformity means it's impossible to upgrade the whole thing in one shot, and creates opportunities for bugs both in the initial writing and when the code needs to be maintained. By factoring out the code there's no possibility for bugs because you aren't writing new code.

flUpdate, a boolean, if true the Tool is updated every night along with opml.root and the other updating roots.

prefs, an outline, contains the prefs page for the Tool. Here's a screen shot of an example. Refer to the prefs outline for the OPML Editor, opmlEditor.data.outlines.prefs, for more varied examples.

uninstall, a table. Each item is the address of an object outside the Tool's database that must be deleted when the Tool is uninstalled.

onInstall, a script that runs immediately after the Tool is installed. It could open a prefs page, or help text, or perform some one-time initialization. podcatcher.root uses this feature.

That's it for now. This list will certainly grow.