Macrobyte Resources Conversant Developer Central
Internet groupware development platform
RE: Plug-in architecture




 
Subject RE: Plug-in architecture
Posted 5/23/2002; 7:54 AM by Greg Pierce
Last Modified 5/23/2002; 7:54 AM by Greg Pierce
In Response To RE: Plug-in architecture (#241)
Label None. Read 1000
<Previous Next> Thread: Edit Reply
On Thu, 23 May 2002 06:06:29 -0400, David Davies wrote:

>I've kind of answered my own question by downloading the trial version of Conversant and I've had a >first look at the anatomy of a Conversant plugin. I understand that Manila plugins won't work out of the >box but I expect a port is possible, especially if the plugin in question isn't too reliant upon Manila or >mainResponder, which mine isn't....

It would certainly be easier than porting a Zope product or something, but it will still require some work. It depends on what your plugin does how much work it will be. Conversant has an entirely different API, and entirely different macro engine, so they'll be a lot of changes necessary.

>Are there any doc available to help a potential plugin developer get started?

Sadly, no. We're just getting started on developer docs. :-(

There is an API call to create a plugin, I suggest you use that to get started...in QuickScript, run:

Conversant.plugins.create( [nameOfPlugin] )

This will automatically create the plugin, and place it in the "Conversant Plugins" folder so that it will be registered on restart of Conversant. Once you have created it, you need to go activate it on the system level by going to the admin interface under the "System" area ( button at top ) and selecting "Preferences" -> "Plugins" ( tab ). You have selections there for activating and deactivating plugins there. You also have checkboxes to determine whether that plugin will be active in new zones by default, or if it is even available to zones admins to toggle on/off.

At startup, Conversant loops over the "Guest Databases/Apps/Conversant Plugins/" folder and opens each GDB file. For each root, if there is a "Conversant Plugins" table at the root level, it loops over the entries in that table, and looks for a plugin by that name at the root level of the GDB, and registers it with the system. Look in "Conv_basePlugins.root" to see the set in action.

Like I said, the API call will set all that up for you, however.

At the zone level you have similar options for enabling/disabling plugins for whole zone, and whether conversations can enable/disable them.

Plugins are _not_ global in Conversant.

>Any pointers will be gratefully received!

We'll be working on docs in the coming months -- but please feel free to ask questions here. We'll do the best we can to keep you moving along in the meantime...

g.

<Previous Next> Thread: Edit Reply
ENCLOSURES

None.
REPLIES

RE: Plug-in architecture
5/23/2002 by Seth Dillingham
On 5/23/02, Greg Pierce said: >>Any pointers will be gratefully received! >

RE: Plug-in architecture
5/23/2002 by David Davies
Hi guys OK, I've made a plugin, restarted Conversant and activated my plugin



 
© 2002 Macrobyte Resources. All rights reserved.