16th June 2021

Attendees

• Ivar Grimstad (Eclipse Foundation)
• Ed Bratt (Oracle)
• David Blevins (Tomitribe)
• Jonathan Gallimore (Tomitribe)
• Emmanuel Hugonnet (Red Hat).
• Daniel Kec (Oracle)
• Tanja Obradovic (Eclipse Foundation)
• Luke Saker (IBM)
• Reza Rahman
• Clebert Suconic (Red Hat)
• Ondro Mihalyi (Payara)

Minutes

• (Ondro) EE Messaging 3.1 plan as was approved recently didn’t have high goals, maybe we can add new features, but we aim here to discuss longer plans for EE Messaging
• (Clebert) JMS is more than 20 years long and has a lot of legacy, which isn’t needed anymore and there’s a lot of usecases where it’s complicated or not possible to use it in the current state
• (Reza) Presented a document that triages existing issues into categories and priorities
• (Ondro) An idea: old API should be separated or maybe even create a new messaging spec side by side with the old spec
• (David) it makes sense to separate the old API and and make it optional, maybe even create a “lite” profile with only the new API
• (David and Clebert) The new API should be simple and allow that semantics are up to the implementation
• (Ondro) We should revisit MicroProfile Messaging because they tried to achieve a similar goal
• (David) it seems we have a consensus
• (Reza) If there’s a consensus, MS (Azure Service Bus team) is interested to join and collaborate
• (Ivar) To confirm a consensus, there should be a vote
• (David) if we leave semantics to the implementations then it’s possible to find a good trade-off between speed and reliability by choosing an appropriate implementation
• (David) We should create a new issue to cover the “lite” profile or reuse existing related issues - optional/relaxed delivery semantics and guarantees, etc.
• Some existing related issues
  • New “relaxed message order” option (#91)
  • fit well for JMS over Kafka (#210)
• (David) Let’s have an issue for each specific guarantee to relax them or make them optional
• (David) Presented a proposed structure for the messaging-propsals repository, with a structure in the README file for each proposal, for example README for JSON-B proposal