Re: [messaging-dev] New API Requirements Was: Browsing / Streaming...

[Reza Rahman <reza_rahman@xxxxxxxx>]

Yep. We came to that realization in the JMSContext conversation. To be honest it would be great to think about whether producer and consumer needs to separate APIs either.

 

---

From: messaging-dev <messaging-dev-bounces@xxxxxxxxxxx> on behalf of Clebert Suconic via messaging-dev <messaging-dev@xxxxxxxxxxx>
Sent: Friday, March 14, 2025 10:38 AM
To: EE4J Messaging project developer discussions <messaging-dev@xxxxxxxxxxx>
Cc: Clebert Suconic <csuconic@xxxxxxxxxx>
Subject: [messaging-dev] New API Requirements Was: Browsing / Streaming...

 

Another thing I would do on the new API: No need for Session.


Just Connection -> Consumers

        Connection -> Producers

(notice: I'm not assuming we will call them Consumers and Producers yet).. the point I'm making here is I'm trying to not use the concept of a Session.

If needed I can list a number of reasons for removing the Session concept. At this point I think it's obvious and if someone disagrees I can list the reasoning here.

On Thu, Mar 13, 2025 at 4:56 PM Matt Pavlovich <mattrpav@xxxxxxxxx> wrote:

Having a single way to receive anything in terms of Messaging would be a dream come true :)

Love it!  Let’s do it ;-)

On Thu, Mar 13, 2025 at 4:03 PM Matt Pavlovich <mattrpav@xxxxxxxxx> wrote:

At this point it seems to a good idea to have these two concepts differentiated... Queuing and Streaming..  

Why do you think it should be differentiated? What is the difference to a coded application to handle this that couldn’t be handled in a configuration flag instead of a change in class used in the API?  The original JMS API had this same type of paradigm that became an issue when using topic v queue. This approach required a code-change to switch destination types instead of being able to adjust a config value.

I think it would be better to have a simplified API that is a reader and the only difference if you want stream (no ack) or read (ack) is some sort of config flag or ack mode.

Thanks,

Matt Pavlovich

On Thu, Mar 13, 2025 at 11:09 AM Reza Rahman via messaging-dev <messaging-dev@xxxxxxxxxxx> wrote:

I would first need to understand more about the use case to be honest.

Is this the same as the existing browsing use case or is it actually consuming messages off a queue? If the latter, this would be an imperative alternative to MDB style declarative message consumption?

---

From: messaging-dev <messaging-dev-bounces@xxxxxxxxxxx> on behalf of Clebert Suconic via messaging-dev <messaging-dev@xxxxxxxxxxx>
Sent: Thursday, March 13, 2025 11:00 AM
To: Matt Pavlovich <mattrpav@xxxxxxxxx>
Cc: Clebert Suconic <csuconic@xxxxxxxxxx>; EE4J Messaging project developer discussions <messaging-dev@xxxxxxxxxxx>
Subject: Re: [messaging-dev] Browsing / Streaming...

 

well.. you have things on a certain context... 

you could maybe even reuse some of the Java Streams API, expand perhaps?

On Thu, Mar 13, 2025 at 10:43 AM Matt Pavlovich <mattrpav@xxxxxxxxx> wrote:

Naming is hard! The first thing that jumped out at me is that ’streaming’ is confused with the Java ’streams’ language feature. I lean towards ‘Event’ since it is shorter (and not as over loaded).

Matt Pavlovich

> On Mar 12, 2025, at 2:40 PM, Clebert Suconic via messaging-dev <messaging-dev@xxxxxxxxxxx> wrote:
>
> I'm planning to spend some time next week writing some ideas...
>
>
> But before I spend time on it.. I wanted to ask something...
>
>
> There's the concept of a Browser in the current JMS API. What if we called it Streaming?
>
> You would have a differentiation between Queueing semantics (single destination polling messages between multiple endpoints) and Streaming semantics where all the messages from the destinations are received.
>
> It's the same concept in the end.. but maybe Streaming would be a better name for a newer API.
>
>
>
> _______________________________________________
> messaging-dev mailing list
> messaging-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://accounts.eclipse.org

_______________________________________________
messaging-dev mailing list
messaging-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org

_______________________________________________
messaging-dev mailing list
messaging-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org