Announcements and unsubscribing - best practices?

Hi,

Announcements and Seaside give me some trouble due to missed unsubscriptions. So I am looking for best practices for unsubscribing from events.

First, let me shortly explain the problem:
My approach to Announcements was stolen from Ramon's blog, and from the (great) Seaside online book.
I usually call: or show: a new instance of a component or embed one into a component and at the same time register my calling/embedding component as subscriber to some events that get announced by the embedded/called component. All works well. For a while. Because the subscriptions linger around forever, and so the calling component will react to Announcements that come from another component than the one it once created and called/embedded. Say you announce an AddObjectAnnouncement from several components in your application and more than one component registers fro this announcement, how do you make sure only the "currently active" component receives an announcement?

So what do people do to avoid multiple or old subscriptions? What is a good point in time to unsubscribe (using removeSubscriber). There is not necessarily an answer: method in components, because it's possible some link or button on the screen (main menu, toolbar) simply call:s another component without notifying the active compoenent, so the one that has subscriptions will not be removed or garbage collected.
So neither overriding answer: nor adding unsubscription to #release of subscribers will do.

The only thing I can think about that would probably work is to implement a central manager that keeps track of who is active and all call:s or show:s need to be handled by this manager. This manager could be the session (what a sick idea...).
This would somewhat lead the whole decoupling idea of Announcements ad absurdum, wouldn't it?

Is this an academic question? No, it's not. It's easy to mess your application by forgetting to unsubscribe. In some cases, GLORP tries to delete an Object twice, because some Components are still subscribed and have not been garbage collected yet, so both send a delete: to GlorpSession, and the second one gets an SQLCode 100 because the row to be deleted is not existent any more....

Thanks for reading and also for your answers and comments.

Joachim