C#

smesser wrote:

Thanks for the dialog as it is more helpful than you realize. You make me think about this in
ways that I may overlook. It's always nice to bouce idea around.

void CreateEvent(string eventName);

void Subscribe(string eventName, SendOrPostCallback callback);

void Unsubscribe(string eventName, SendOrPostCallback callback);

void Send(string eventName, object state);

// Event

IMessage message = System.NewMessage( "music.event.endofsong");
message.Send();

// Message send from somewhere wanting to tell the music play to play a playlist.
IMessage message = System.NewMessage( "music.queue.list" );
message[ "song 1"] = "song.mp3";
message{ "song 2"] = "song2.mp3";

IMessage message = System.NewMessage( "music.play" );
message.Send()

// Subscribe to an event done while plugin is being loaded at app startup.
System.Subscribe( "music.event.*");

// In the meantime the song get to the end so the music plugin sends
IMessage message = System.NewMessage( "music.event.endofsong" );
message.Send();

By convention given my continuing example.

music.play            // message to tell plugin to play whats in it queue
music.stop            // message to tell plugin to stop playing music
music.event.endoflist // message/event from plugin to subscribers notifying of end of playlist 
music.event.endofsong // message/event from plugin to subscribers notifying of end of a song

smesser wrote:

Now this is really getting exciting... Programming is exciting right ????

smesser wrote:

One thing is starting to get a little fuzzy for me. That is the difference betweek a message and an event. I have been kind of picturing them as one in the same.

EventQueue eventQueue = new EventQueue();
int endOfSongEventID = eventQueue.CreateEvent("EndOfSong");

eventQueue.Subscribe("EndOfSong", new EventQueueEventHandler(HandleEndOfSong));

private void HandleEndOfSong(object sender, EventQueueEventArgs e)
{
    // Do stuff in response to EndOfSong event.
}

eventQueue.Send(endOfSongEventID, this, null);

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.