Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[messaging-dev] Meeting minutes from 16th June 2021
Hi all,

Here are minutes from our meeting the previous week. They are published at https://eclipse-ee4j.github.io/messaging/minutes/2021-06-16.html. I copy the minutes also here:

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
  • (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

Back to the top