Re: [computer-go] Event-driven programming

[Patrick Stiegeler <stiegele@xxxxxxxxxxxxxxxxxxxxxxxxxx>]

>> i think, i did something like what you call "event-driven programming".
>> i use a singleton which i call a NotificationServer and which handles
>> all the message passing:
>
>So  you only have a single NotificationServer?  How do you determine
>which listeners get which events ... or do you just send every event to
>all listeners in the entire system?

I have a single NotificationServer. The static method
NotificationServer.instance() just returns the one and only instance.
Determining which event is to be sent to which object is subject to the
NotificationServer and depends much on your needs. Sending every event to
all listeners should certainly be avoided.

Each notification observer registers itself (maybe multiple times, for
different events) to the server with a description of the event(s) that
it's interested in.
It depends on your application if you want this to be:
    - just a simple number ("event no. n occurred")
    - a pattern to be matched: (<sending-class>, <message-class>, ...)
      with "null" at each position meaning "whatever value"
      and <sending-class>    matching all events sent by an object of
			     class <sending-class>
      and <message-class>    matching all events beeing a <message-class>
			     or having it as a super class
    - ...
      you may define your dedicated event-patterns, because this matching
      process is a crucial point to loose or save computation time.
      with a pattern scheme, that depends on the possible events, you are
      able to precompute some attributes of the patterns, so that when
      given an event, you may navigate quickly to the apropriate observers
      to pass the event to.

another issue is, whether messages for an observer should be sent one
after the other or alltogether as a whole, again depending on your needs.
in the latter case, you may need to organize your code, so that a
"hey all: send your events" phase is alternated with a
"NotificationServer: dispatch events!" phase.
(For which in turn you might use the NotificationServer in "dispatch
immediately" mode)



further on, if you have message sending objects or message observers
running in different threads, you should think about synchronization: are
there message sending objects, for which it is nescessary to assure that
the event is consumed as the NotificationServer.instance().notifyEvent()
method returns?

these considerations are rather general. therefor I should mention, that
my NotificationServer is not really in the domain of go; so excuse me for
not stating any details on how to use it in a go evaluation ;)


>> i hope, this helps you a bit...
>
>Yes, it does.  If you have any papers on this, I'd love to see URLs.
>
Sorry for that. I don't know any paper on this topic.
But you may want to have a look at something called a "tuple space" (just
google for it...)
It is a so to say asynchronous and passive version of a NotificationServer
and maybe you want to
know about it.



>> btw: i would call this "event-driven programming", too.
>>      in the real world ;) there are many examples of
>>      different subject areas having different notions of
>>      the same word.
>
>When I realized that an event server of some kind would be necessary, I
>thought this might be closer to event-driven.  It doesn't exactly sit
>and wait for events, but it does keep asking, "What's the next event in
>the queue?"
>
Indeed, the event drives the action. Event -> dispatch -> Observers'
action(s).




bye,

	patrick
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://computer-go.org/mailman/listinfo/computer-go