plugin system

Registered by Vadim Peretokin

An easy to use and powerful plugin system is definitely needed. However, what control exactly should the plugins get? And how should they be given this control?

Blueprint information

Status:
Complete
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Approved
Assignee:
None
Definition:
Approved
Series goal:
None
Implementation:
Implemented
Milestone target:
None
Started by
Vadim Peretokin
Completed by
Vadim Peretokin

Related branches

Sprints

Whiteboard

Vadim:
I think the callbacks that mudbot offers (and those are, when plugin is loaded, unloaded, when a paragraph is received, when a user input is received) are quite good for dealing with text. However, how to deal with the GUI-related things?

Larkin:
MUSHclient has a lot of plugin callbacks, and so it does checks in a LOT of places for when to notify plugins of all the various events. If we're going to do something similar, the logic for notifying plugins would have to be well encapsulated to avoid repeating the same things too much. Personally, I'm a huge fan of the way C# allows handlers to be added and deleted through delegate functions. I've seen similar code for C++, though I can't remember where now, so it should be possible for us to work with it in a similar way. (?)

My main gripe with MUSHclient plugins is that they have their own script space, preventing them from setting world variables directly (I have to use custom aliases instead). Nick did this because he wanted to allow mixing of script languages, as far as I'm aware, so using only Lua can allow circumvention of this limitation.

PenquinCoder:
I like the aspect of MUSHclient plugins. Allow them to interact with the normal world, and the normal world to interact and change the plugin scope. IE Variables, trigger sequencing etc. However, I don't think that plugins should have the ability to modify existing 'main' world variables/plugins/aliases. If this is to be done, it might mess up when a plugin changes an already existing main world variable or such, causing the rest of the main world items to go out of sync. Keep plugins in their own scope, but portable.

Extra idea: Make a plugin creator?? Akin the MUSHclient's, let user create their own plugins from existing script files, triggers/aliases/timers

Nickpick:
Plugins are an essential part of many successful OSS programs. Even if the program itself becomes inferior, or less popular, with time, the plugins can still raise its usefulness and let it compete against the new solution, as well as implement its aspects behind the scope of the original developer. *deepbreath* The more we can stick unto the client, the better.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.