• Welcome to Valhalla Legends Archive.
 

Extensibility Design Issue

Started by MyndFyre, May 04, 2004, 12:08 PM

Previous topic - Next topic

MyndFyre

In your humble opinions, which way should I make my bot extensible:

1.) For a plugin, pass the actual connection manager instance into the the plugin so that it has both the connection manager *and* the EventHost instances?  That way it could send binary packets directly or text through the message queue.
2.) Give it just the EventHost instance, and then require that it implement (via an abstract class that it must inherit) certain events, such as TextToSend, PacketToSend, etc. ?
QuoteEvery generation of humans believed it had all the answers it needed, except for a few mysteries they assumed would be solved at any moment. And they all believed their ancestors were simplistic and deluded. What are the odds that you are the first generation of humans who will understand reality?

After 3 years, it's on the horizon.  The new JinxBot, and BN#, the managed Battle.net Client library.

Quote from: chyea on January 16, 2009, 05:05 PM
You've just located global warming.

Eli_1

I like the second option.  ;D

MyndFyre

#2
OK, here's what I've come up with so far:

public abstract class PluginBase
{
 // Delegate Information

 // InfoEventHandler
 // Defines a callback with the format:
 // void (string)

 // ChatEventHandler
 // Defines a callback with the format:
 // void (string, UserBase)


 // The bot should send this as normal chat to Battle.net
 public event InfoEventHandler PluginMessage;
 protected virtual void OnPluginMessage(string Text)
 {
   if (PluginMessage != null)
     PluginMessage(Text);
 }

 // The bot should just display this as a logged event
 public event InfoEventHandler InfoDisplay;
 protected virtual void OnInfoDisplay(string Text)
 {
   if (InfoDisplay != null)
     InfoDisplay(Text);
 }

 // The bot should display this as a user event
 public event ChatEventHandler UserChat;
 protected virtual void OnUserChat(string Text, UserBase User)
 {
   if (UserChat != null)
     UserChat(Text, User);
 }

 // Gets a user control instance that I designed, or a derived class,
 // that will be shown in the bot configuration window.
 public abstract PluginConfigurationBase ConfigurationPanel { get; }

 // Gets a set of name-value pairs that can be easily persisted
 // in XML format.  See below for the XML definition.
 public abstract StringDictionary PersistableSettings { get; }

 // Initializes the plugin with the event model provided by the bot,
 // as well as the settings from the XML file.
 public abstract void Initialize(IEventHost EventHost, StringDictionary PersistedSettings);
 // Causes the plugin to release tell the event host to
 // release all function pointers pointing to it.
 public abstract void Release(IEventHost EventHost);
}


Remember, the IEventHost class provides the following functions:
C#:

RegisterEvent(EventType Type, MulticastDelegate Handler);
UnregisterEvent(EventType Type, MulticastDelegate Handler);

VB:

Sub RegisterEvent(ByVal Type As EventType, ByVal Handler As MulticastDelegate)
Sub UnregisterEvent(ByVal Type As EventType, ByVal Handler As MulticastDelegate)

C++:

// these are equivalents
void RegisterEvent(EventType Type, void* Handler);
void UnregisterEvent(EventType Type, void* Handler);


Thoughts?  Comments?  Flames?
QuoteEvery generation of humans believed it had all the answers it needed, except for a few mysteries they assumed would be solved at any moment. And they all believed their ancestors were simplistic and deluded. What are the odds that you are the first generation of humans who will understand reality?

After 3 years, it's on the horizon.  The new JinxBot, and BN#, the managed Battle.net Client library.

Quote from: chyea on January 16, 2009, 05:05 PM
You've just located global warming.

Banana fanna fo fanna

Here's my self-proclaimed best plugin system ever.

Your "bot" is just a reactor that loads "connection plugins", "configuration plugins", "database plugins", "controller plugins", "logger plugins" and optional "userinterface plugins". Perhaps some sort of "filter" plugins too, I don't know.

I'll just give you a brief overview of what each one is, you're a smart guy, you'll understand.

The reactor basically glues everything together and contains all config settings and stuff.

Connection plugin: connects to a server such as CHAT and SEXP and WAR3 etc. Methods like connect(), sendChat(), etc. Callbacks to the reactor (which are broadcast to various other plugins) for events such as userJoined, userTalk, etc.

Database plugin: getUser() method returns a User object. 1 database plugin per reactor; reactor.getDatabase()

Controller plugins: copy greetbot interface, used for commands and stuff like that

userinterface plugins: could be gui or web or cmd line or something else. Copies much of the interface of controller plugins.

logger plugins: has a log() method which takes a Message class. (both user defined)

Filters: something to massage data (chat modes, ignore dshr, etc, i dont know)