On 2011-05-10 9:13 AM, Henrik Sperre Johansen wrote:
> The amount of nuances and quirks in implementing subscribing/unsubscribing,
> weak versions, delivery guarantees etc. are large enough that you really
> only want to implement/document/learn them once.

FWIW, I agree heartily. Looking at Announcements-klub.1.mcz from the 
AXAnnouncements project, a *lot* of thought and careful implementation 
has gone into the subscription-management and delivery piece of the 
puzzle - and even then, there are areas in which it could be improved.

One way of thinking about it, that I'm becoming more and more convinced 
by is this:

   If Objects are abstract representations of computers, then
   Announcers are abstract representations of networks.

The communication channel between two objects is normally a regular 
message send. Regular message sends provide Plain Old RPC (with 
Exceptions). Sometimes, however, you want one or more of the following 
things to happen:

  - a message to be delivered to more than one recipient
  - a message to be delivered to an arbitrary or unknown number
    of recipients
  - a message to be delivered asynchronously, or without reply
  - a message to be delivered across a real network to some remote
    object

Combinations of the above are useful and interesting too.

It's in situations like these that having a first-class representation 
of the *medium of communication* between objects becomes important. And 
that's just what Announcers are.

(I'm working at the moment a little on thinking about how to generalise 
Announcers to take into consideration more than just the first two of 
the four points listed above.)

Regards,
   Tony