Skip to content
Ondro Mihályi edited this page Mar 31, 2022 · 4 revisions

Welcome to the Jakarta Messaging Specification Project! This is the proper place to come and express ideas or use cases for messaging standards for Java.

Note
All ideas that lead to improvement of the specification are welcome, including use cases and detailed accounting of how the API might be difficult or hard. Everything submitted will be discussed for weeks, months or years. If you have an urgent Messaging issue, this is not the right place.

Use Cases and Proposals

Often times when we imagine a problem we can think of several ways to solve it. We tend to pick one and present that to the world, starting the discussion with the solution; "we need x."

Congratulations, you’ve executed a mini-specification exercise alone, start to finish. The same process must happen with everyone included, start to finish. For this reason, we ask:

Here is the workflow that split enables:

  • Step 1: As a community we will flush out the use case, make sure everyone understands it and discuss the value of the problem. If we don’t agree on the problem, we can’t agree on a solution and we are stuck.

  • Step 2: Several ideas on how to potentially solve it will hopefully emerge. Each should become a proposal that is filed separately and linked to the use case issue. Consider submitting all the potential solutions, even the bad ones.

  • Step 3: Proposals that are well-defined enough to be prototyped, hopefully are prototyped. Lessons are learned. We potentially see something complicated in the problem we initially missed.

  • Step 4: We decide if any of the solutions to the problem are worth the cost.

  • Step 5: We have solution we like, so we can move forward and develop specification text and TCK. Hopefully there is a prototype.

  • Step 6: We want to release our awesomeness to the world! An implementation is now mandatory.

use case

Anyone can submit a use case issue and there is no requirement you have any proposed solution. You are 100% encouraged and will be applauded for submitting a juicy use-case for others in the community to chew on. Problems looking for a solution are significantly better than solutions looking for a problem.

Your submission should have:

  • A code snippet or description to illustrate

  • A clear and short bulleted list of the pain points

Perfection not required, just do your best.

proposal(s)

If you have ideas on how to solve your use case, filing the solution separately:

  • enables others to submit potential solutions along side yours.

  • enables you to submit solutions other people’s problems without having to restate 100% of the problem description

  • enables you to easily submit all the good and bad ideas you had — maybe someone sees a way to make the "bad" idea work and then it becomes the idea you both love

  • avoids situations where people are proposing solutions to two slightly different problems (and therefore get nowhere)

The last bullet seems funny, but is more common than you might think. Frequently a proposal reminds someone of a related problem they had once. They enter the discussion with good intentions. If you started the discussion with a proposal and thinly defined use case, then all the time wasted is on your shoulders.

Proposals can start out rough. Be aware:

  • they eventually need to become detailed enough to implement

  • someone may even try implementing it and as you questions

Links to your blog are not suitable proposals. For Intellectual Property and Patent reasons, you must copy/paste the entire contents into the issue to clearly signify it is being offered under the Eclipse Contributor Agreement.

Please consider the following legal issues you’re introducing when you submit links as a proposal:

  • The phrase "this is my idea <link>" can just as easily mean "you’ve been notified you’re infringing on my idea" as it can mean "I offer this idea for inclusion."

  • Your blog or the platform that hosts your blog has its own licensing. You are likely the only one with authority to change it. No one else but you has the legal authority to copy from your blog and paste into a spec.

Proposals that are links will be rejected.

Clone this wiki locally