I'm implementing a global blackboard for posting events and subscribing to them and I'm wondering about the best method to prevent cycles.
Since this is e.g. for 'model-change and 'view-change events, I cannot generally guarantee that clients (subscribers or notifiers) have a "direct program flow" from event reception to notification of another event. For example, in an event-based GUIs like Racket's the program flow may look like this: model change-->model notifies view of 'model-change-->view receives 'model-change-->view changes GUI class-->external library and OS-level widget display handling-->GUI class event-->view notifies model of 'view-change "view notifies model of 'view-change" has no way of knowing in general & for sure that it was caused by "view receives 'model-change". Receiving 'model-change and sending of 'view-change may even occur in different threads. Right now my plan is to make the blackboard keep track of notifications sent, let the programmer mark that 'model-change and 'view-change are to be cycle-free, prevent notification based on the sent notifications and the notifiers and subscribers involved, and remove the corresponding information about a past notification once a cycle has been prevented. Unfortunately, this will fail if the view for some reason such as an error chooses not to send a 'view-change event to the model after the view change was caused by 'model-change. In that case, the blackboard cannot remove the original notification and the next 'model-change by view will be blocked. This can cause data loss! Is there a better solution to this problem? How do mature notifier/subscriber frameworks deal with these kind of problems? Best, Erich -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
