Refactoring the Event module (or not)

[darius (Darius Jazayeri)]

@mseaton

Will the atomfeed module just have an Interceptor that is concerned with it’s own use case (recording an entry on the feed), or will the atom feed module also contain the code needed to subscribe to events with a callback that can be executed within the current transaction?

I was expecting the following:

Near Future State

• atomfeed has an interceptor only concerned with its own use case, with minor changes per Wyclif
• event module stays as-is (i.e. keeps it own interceptor)
• openmrs-core introduces a new callback-on-db-change API, but this is only available from 2.2.0.

Later

• we have a module like “callbackondbchange” which is a compatibility module providing this functionality for versions of openmrs core < 2.2.0
• atomfeed is aware-of callbackondbchange, and will conditionally use either openmrs-core or this
• even module is aware-of callbackondbchange, and will conditionally use either openmrs-core or this

Now that I have written this, it seems like it actually makes sense to write the callbackondbchange module first and then move its code to openmrs-core after some testing.

(Mike I think you’re suggesting that we should just put this new API in atomfeed for now to avoid having yet another module and because atomfeed seems to be becoming a recommended module. I understand that motivation but I’d still vote for putting in in a single clean module, that will no longer be required after the next core release.)

Also, note that the Event API is actually based on JMS, and we wouldn’t actually want this exact API for the “callbacks within hibernate interceptor” module.