Open ctrueden opened 10 years ago
@ctrueden Thanks for the heads-up. At the moment, the proposed design of the notification feature would provide a "firehose" of event messages. The initial version will simply feed all event messages, and leave it to clients to filter based on what messages they're actually interested in. In the future, we may want to also allow clients to register for specific event messages (which it seems like might be a better fit with this feature), but that will probably not happen for a while. I'll definitely keep this in mind, though, as we're designing the API.
@jballanc please note that there are other event processing libraries out there which are already tested and stabilized over years. Maybe a good idea to look into them instead of inventing another one?
@dscho Sorry for not being more specific. We're going to be using HornetQ to handle the messaging so Java apps will have the option of using HornetQ or any other JMS capable library for getting messages. For other languages we also have a STOMP adapter that'll be available. The remaining work consists of mapping OMERO's internal Spring-based events to HornetQ messages. Presently we're broadcasting every event, including things like login, session creation, etc. In the future we might want to provide specialized JMS topics for specific message types (for example, only messages dealing with image changes).
@jballanc: Thanks for the info!
After opening an image (e.g., with ROIs) from an OMERO server, some sorts of data structures such as ROIs can later change on the server side. For the life of the image staying open on the ImageJ side, it should receive such notifications and act on them somehow (e.g., tell user, or just update them automatically).
@jballanc: @joshmoore mentioned that you are working on push notifications from OMERO, so FYI, here's a potential use case for you.