@darius, thanks for posting this - this is a very helpful summary. I don’t think I’m free for the design all on Wednesday (@jthomas FYI), but I like your approach. I’m not sure we need yet another module. What if we have a single module that contains both the synchronous, transactional event notifications (with the interceptor) and the atomfeed implementation.
For argument’s sake, let’s say we make the atomfeed module into this (since it already has all of the atom feed code and also the copied interceptor). Then we move the small number of classes from the Event module into the atom feed module so that they can be used there and maintain backwards-compatibility (eg. they would still be org.openmrs.event). Then we re-write the Event module to depend on the atomfeed module.
I’d suggest that then the atomfeed module would become a part of the reference application, and the event module would no longer be included, and registrationcore would be updated to depend on the atomfeed module as described above.
Thoughts? Mike