Talk:Plugins

From PsiWiki

Please don't use dynamic linking! Use an interpreted language instead (python?). Otherwise we'll end up with platform-specific plugins, as most developers certainly won't care about other platforms than the one they use. And it won't encourage the development of free software plugins either. --81.86.232.182 11:07, 10 March 2007 (EST)

Little work of Petr Mensik aka Pihhan follows.

I dont think interpreted language should be available on all platforms. Implementing own psi language to do extra features is really overkill. But it might be possible to make plugin for executing interpreted "plugins". So it would provide bingings to other language. But i am not sure how much memory would consume having more plugins with each runtime machine for each plugin.

Contents 1 my view of plugin system 1.1 What we need plugin for? 2 How to do plugins 3 Implementing vs. Current implementation 3.1 Problem: 3.2 Proposal:

my view of plugin system

I think Qt plugins are good way to go. But i think there should be different way to work with plugins than internal code does now.

What we need plugin for?

• Popups - to be able to do popup, what do we need? what does growl accept for example? I think we need generic popup interface and have to know what would it be able to tell us. There are some things.
  • Type of popup. Do we show message, chat, presence in, out, subscription?
  • Some info about sender. That is propably his JID, roster status, with his status icon, maybe his avatar image. So we can do it nice, if popup system is able to show popup with icons.
  • Text of message or status. This is why we are doing popup.

• Messages - handling of messages, such as specialized history, simple robot in psi.
  • We need information about sender, jid, nickname, status.
  • We need message. I think plugin should receive full XML tree of stanza, not only body part. So it can write blog for example with html or i dont know. So it can work with namespaces Psi itseft does not understand.
  • To allow autoresponder plugins, it should be able to reply and/or send new message.
  • Should it be able to "eat" messages? So they would never arrive to user? For example in dnd status, it would reply: "Dont bother me now", and queue message for user when he switch from dnd. Or allow implement privacy list on client side when server does not support it.

• Presences - to allow publishing status of user to other programs, using dbus, DDE, i dont know. Should be able to find using bare jid (most important - highest priority - if there are more) or full jid.
  • Need to get my own global status and status per account.
  • Get status (only show element, or with status text description?) of any JID, with specified account or first found on any account. For example to show status icon in some addressbook program.
  • Get current icon or avatar image, or get its path on system if possible. It would be good to return different icon based on connection state and type of contact (user from icq/msn gateway, depends on how you set that).
  • Should it receive full XML stanza, or only some State structure?

• Iq - allow extending current psi functionality
  • Allow registering new namespace support. This plugin will handle all iq packets with given xmlns.
  • Should it be able to decide to "eat" packet? It has to receive full XML stanza. But should it allow block iq packet from other plugins? If yes, we need some priority number, or let user change order of loading plugins.
  • Allow sending stanzas.
  • Allow registering id of stanza, so pluginmanager will deliver also replies without explicit xmlns.

• User interface
  • Allow very basic psi interaction, as is show or hide roster window and chat windows.
  • Allow plugin register some submenu. It might be in submenu plugins from main menu. There, it will enumerate all registered submenus and display it to user.
  • Allow changing global status. Propably only simple state and text, nothing special.
  • Should we allow some special interface for chat dialogs? For example, voip plugin might want put somewhere telephone icon to start calling, but only for supported user. I think there should be function in each plugin with user interface modification, which we will ask should i call your menu widget for this user (does this contact support telephony?)
  • I think at start we should not allow changing whole dialogs (disco, chat, groupchat) from some plugins, it is propably not so easy at this point, when no plugins are working well.

• Configuration
  • Read some entry from configuration.
  • Read entry from only running configuration.
  • Modify entry in only running configuration (do not save configuration). Useful to get our own public IP address using STUN or get proxy65 address from server only this time. Or get system configuration of http proxy, useful for Psi on flash disk.
  • Write configuration to disk. Propably return success.

• Passwords
  • Allow plugin register as password handler. So, if password is needed, call plugin to get some. We should pass who needs password (JID of account). And maybe type of password we want to know (chatroom, PGP, xmpp connection?)
  • Allow using hashes somehow, send hash to plugin and get some response.
  • Allow plugin to be called to authenticate something itself. Would be great to have single-sign-on capability. Simply ask system authenticate me as JID xy? I am not sure how exactly this works, would be fine if we could ask kerberos or Windows system to authenticate us. Needs investigation. May be used for SASL external.

• Sound player
  • Simple plugin, will register as sound player. If psi does want sound played, it does pass it to plugin (if configured so). If there is such plugin, it might receive name of event ("presence.online" etc.) or name of file to play ("/usr/share/sound/ding.wav"), or both.
  • Players can vary, i can imagine also visual player, which will popup or blink icon of some action. Useful for places where you have to be quiet, like lesson in school.
  • Should we allow more than one sound player at time? Usual there should be only one, or noone if we dont have sound.
  • Should plugin handle mute action, or should it handle Psi itself by not sending any events to sound player?

• File transfer plugin
  • Communication should be done as Iq packet plugin. Data transferring would do plugin, not psi. Psi would only offer filename and destination?
  • Allow hooks for start of transfer, end of transfer, error in transfer, maybe display received file/directory action.
  • There should be hooks for checking received file. Something useful for antivirus, or media player.

• General
  • Each plugin should be able to enumerate accounts and their status.
  • Each plugin should be able to search pro status of some JID. Should there be some plugin abstract of internal class Status?
  • Each plugin should be able to get features for given JID. If contact support caps, return features from listing. If not, should we instruct Psi to get features using disco query? There should be two choices, give me features from caps, and give me features anyhow you can get it.
  • Each Iq plugin should be able to publish its features. PluginManager might do that on plugin registration itself.
  • Each plugin might want to be periodically called. Period should not be very short, something like some seconds or minutes for example, not miliseconds. Not sure if this is needed, plugin might be able to create his own timer or thread if needed.

How to do plugins

I think all should be in hands of pluginmanager. Every single plugin should be called as something like init((PluginMangager *) self, Qstring pluginname) or something. In init of each plugin, plugins would register only to action they are able to do something. So, for example plugin working by reading messages would do:

messagePlugin::init(PluginManager *rm, QString &myname)
{
   rm->registerMessageHandler(messagePlugin::handleMessage());
   // or in case of Qt, maybe only connect() to according slot would suffice, i dont know
   // i dont have much experience with Qt
}

or in case of Iq handling plugin, it would register as generic Iq handler. Or prefferably, it should register only namespaces it does handle.

iqPlugin::init(PluginManager *rm, QString &myname)
{
   rm->registerIqHandler("unr:xmpp:something", iqPlugin::handleIq());
   // or in case of Qt, maybe only connect() to according slot would suffice, i dont know
   // i dont have much experience with Qt
}

Using that system, it would be faster, because every single event would not need to handle every single event Psi does receive. When you would have 100 plugins for example, looping every single event in 100 plugins would not be fast. You know, future is knocking on our door. It would be also safer, as single bad written plugin would crash "only" when it receives its own event, not on any event Psi received. I am not sure if we can use signal/slot signal, as we need for every action to allow more than one receiving handler. For example, we can have more than one parser of messages or presences. But there should be only one for some actions (sound player, iq handler for one namespace). Loading order of plugins should not be random, user might want specify order in which are plugins loaded. First loaded should get event first. Every plugin should be allowed to act as more than one type. So, one plugin class, but with default implementation of most classes as simple return false. Plugin would only reimplement what they need.

Implementing vs. Current implementation

Problem:

The Implementing section seems to strongly contradict the Current Implementation section... I.e. to me dynamic library loading and symbol discovery seems unnecessary when using QtPlugin.

Proposal:

The Implementing section should be revised.

--dschridde 08:56, 5 March 2008 (EST)