Topic: Plugin architecture

[Brad Stone]

I have some ideas for a plugin system, but today I found this very nice article
http://www.icsharpcode.net/TechNotes/ProgramArchitecture.pdf

Its probably more complex than we need but it's got some very nice ideas in it.

I'd love to work on this, but if anyone else wants to have a crack at it, I won't be devastated... If I do it, I'm going to start with the mineral calc as that is a very simple and very standalone form.

[Trigo]

Sounds like what FFET's EMS is aiming for just now but they have had a lot of RL stuff to deal with as of late.

[AndersChydenius]

I wish I had time to play with this, it's the sort of thing I could really sink my teeth into ><

[Brad Stone]

I've attached a first stab at a Plugin Interface to ticket 476

I knocked this up for discussion, I'm NOT saying this is set in stone by any means but its tehre to stimulate discussions.

[AndersChydenius]

Here's some questions that I already know the answers to, but let's discuss them, because my answers could be sub-optimal or even *Gasp* wrong!

Think about the right way to do these things:
-Start/stop plugins while evemon is running
--start/stop all plugins, or one at a time?  allow the user to select "bloaty mode" (1 appdomain per plugin) or "streamlined mode" (1 appdomain for evemon, 1 appdomain for plugins), or optimistic mode (everything in the same space).  Is one of these obviously right?
-allow plugins to have different trust levels; official evemon plugins might have access to everything, untrusted plugins would have access to nothing but the data in your character xml and maybe some timing events

I envision the omega plugin system as involving an extension of our current patch system.  (Another reason why I'm resistant to clickonce).  I see the user hitting the 'get plugins' button and seeing a list of official plugins, downloaded from the evemon site.  These are trusted, certified, signed plugins that we guarantee.

The user could also open a plugin package from somewhere else, which would contain, at the very least, a dll.  .NET packs enough data into the assembly that a manifest file is unnecessary, but we do need to inspect that metadata carefully before we load a plugin package.

We could also have a semi-standard update format, so a plugin could tell evemon "oh, get updates to me from X", and then it would integrate right into our update system.

Just thinking out loud here... back to work ><