C#

smesser wrote:

I like the idea of having an event id but I see a problem with it. As you mention you could request a list of all events available. Since the list would probably return human readable strings
it would make sense to have a plugin face that used strings to refer to them and an id for internal house keeping.

smesser wrote:

If I requested a list of music events and the resulting list was 100, 123, 235 then you would have to maintain another list as to what they mean. And if the id aren't constant each time the app runs it could break the plugin. For example if id 5 means play. My code looks for a 5 the next time but now it's a 6. Just a thought.

int eventID = eventQueue["EndOfSong"];

smesser wrote:

I think there is definitely room for two approaches here. The Callback delegate would be a good approach for most applications but for mine I think it would be better to let the System object have access to the eventqueue and the plugin manager and send out the messages via that path.

smesser wrote:

Each plugin has a function called bool OnMessage( ISystem SystemObject, IMessage Message);

It could return true/false if consumed or not and use the system object to create message to send the replies or responses.

smesser wrote:

Okay so we have an EventQueue which has a number of events in it. Since the EventQueue itself
does not do the dispatching of the messages there needs to be some mechinism for seeing if there are any queued meesages and if so dispatch them.

smesser wrote:

Are you going to share your EventQueue that you have been hammering out?

smesser wrote:

Are you just banging this out for me or will you have an example to use the EventQueue class?

public class MySystem
{
    private EventQueue eventQueue = new EventQueue();

    private MusicPlugin musicPlugin;

    public MySystem()
    {
        // Create events.
        eventQueue.CreateEvent("Play");
        eventQueue.CreateEvent("PlayingStopped");

        // Create music plugin and give it the event queue.
        musicPlugin = new MusicPlugin(eventQueue);

        // Subscribe to the playing stop event.
        eventQueue.Subscribe("PlayingStopped", new EventQueueEventHandler(HandlePlayingStopped);
    }

    private void HandlePlayingStopped(object sender, EventQueueEventArgs e)
    {
        // Logic for handling playing stopped event.
    }
}

public class MusicPlugin
{
    private EventQueue eventQueue;

    public MusicPlugin(EventQueue eventQueue)
    {
        this.eventQueue = eventQueue;

        eventQueue.Subscribe("Play", new EventQueueEventHandler(HandlePlayEvent));
    }

    private void HandlePlayEvent(object sender, EventQueueEventArgs e)
    {
        // Logic for starting playback.
    }

    public void StopPlaying()
    {
        eventQueue.Send("PlayingStopped", this, null);
    }
}

delegateQueue.Invoke(new SendOrPostCallback(delegate(object state)
{
    List<Subscriber> subscribers = (List<Subscriber>)events[eventName];

    if(subscribers == null)
    {
        throw new InvalidOperationException("Event does not exist.");
    }
    else
    {
        subscribers.Add(new Subscriber(handler, context));
    }
}), null);

delegateQueue.Invoke(new SendOrPostCallback(delegate(object state)
{
    List<Subscriber> subscribers = (List<Subscriber>)events[eventName];

    if(subscribers == null)
    {
        throw new InvalidOperationException("Event does not exist.");
    }
    else
    {
        subscribers.Add(new Subscriber(handler, context));
    }
}), new object());

bool OnMessage( ISystem sys, IMessage msg );

IMessage m = sys.NewMessage( "music.play" );
// and then send it.
m.Send();

Leslie Sanford wrote:

The System object could have a hash table where it keeps its messages. When a message is created, the name of the message is stored as a key in the hash table and the message object is stored as its value. Next time someone calls the NewMessage method asking for the same message, instead of creating a new message, the original message is retrieved from the hash table. So only one message of each type is created.

Leslie Sanford wrote:

When a message object is created, it can be passed the EventQueue along with the name of the message. When its Send method is called, the Message sends the message using the EventQueue. So the EventQueue is hidden inside the Message class. The plugins don't have to know anything about it.

class System
    {
        Hashtable hashList = new Hashtable();
        EventQueue eventQueue = new EventQueue();  
        
        public Message NewMessage( string sub )
        {
            Message m = null; // = new Message( "music.play" );
            
            if( !hashList.ContainsKey( sub ) )
            {
                m = new Message( "music.play" );
                hashList.Add( sub, m );
                eventQueue.CreateEvent( sub );     
            }
            else
            {
               m = (Message)hashList[sub];
            }
            
            return m;
        }     
    }
    
    class Message
    {
        string subject;
        string data;

        public Message(string s)
        {
            this.subject = s;
        }
        
        public void Send()
        {
            string sub = this.subject;
            string datium = this.data;

            // what should happen here?
        }
    }

public class Message
{
    string subject;
    EventQueue queue;
    string data = string.Empty;

    public Message(string s, EventQueue queue)
    {
        this.subject = s;
        this.queue = queue;
    }

    public Send()
    {
        queue.Send(this.subject, this, data);
    }
}

smesser wrote:

I thought that the eventQueue was part of the system object.

smesser wrote:

Each instance of message would have it's own eventqueue that would get
disposed of when the message was disposed of taking with it any subscriptions
that may have been made to it.

smesser wrote:

Simple overview:

1. System object creates messages and manages the global eventqueue
2. System object creates and sends events from plugins via the Message send method.
This way there is one global event queue.
3. Plugin has no concept of event queue nor cares about it.

Leslie Sanford wrote:

I think it's number 2 that's giving me trouble. Let's run through a scenario to see if I understand:

1. The System sends a message to a plugin via the OnMessage method.
2. The plugin does something with the message.
3. The plugin wants to send a message telling the System and any other plugins listening that something has happened.
4. The plugin asks the System for a message object representing a specific message, e.g. "PlayCompleted".
5. The plugin gets the message back from the System and sends it calling the message's Send method.

Is this close?

smesser wrote:

5. Close, the plugin would get a the message from the System/EventQueue and either ignore it,
respond to it by using the system object to create a new message and then sending that new
message. The plugin's OnMessage function would return true if the message was consumed.
You wouldn't resend a message sent via the OnMessage function but create a new one if a
response it warranted.

public bool OnMessage(ISystem system, IMessage message)
{
    // Do something with message.
    if(message...)
    {
    }

    // Send a message to system and other plugins:
    IMessage msg = system.NewMessage("Completed");

    msg.Send();

    return true;    
}

public bool OnMessage(ISystem system, IMessage message)
{
    // Do something with message.
    if(message...)
    {
    }

    // Send a message to system and other plugins:
    system.Send("Completed", this, someData);

    return true;    
}