Open Stack

> The original implementation of the notification system was never intended
> to be the *final* implementation. I think we all identified the need for
> versioning several years ago. As for backwards compatibility, I think the
> version field itself, in whatever form it takes, should be optional. If
> not provided, it can be assumed the body of the notification is freeform.

Fair point.
 
> Adding fields is easy. Removal of fields should only occur after we can
> comfortably say that all services are only consuming the new field and
> we¹ve left sufficient time for deprecating the old ones.

Put on the deprecation path, then eventually bump the version when the old
field finally goes away, right?
 
> In some capacity, I think PubSubHubBub has a lot to offer here. The
> publisher has to be able to provide a list of feeds it¹s authoritative
> for, which I think is sufficient for discovery. I think PSHB itself is bit
> heavy weight for what we need (and has some scaling problems) but I think
> the concept itself is very useful for us.

Note to self: learn more about PSHB.
 
> >>  4. external discoverability of which event types a service is consuming
> >
> >Isn't this what the topic queues are for? Consumers should only
> >subscribe to the topics they're interested in
> 
> I¹m not sure I understand the value of this one. A service consumes what
> it consumes. If we¹ve versioned correctly, as mentioned above, why does it
> matter?

Yes, as I said in other responses on this thread, the potential usefulness
of that is rapidly receding in my mind.

Cheers,
Eoghan