Re: [messaging-dev] Browsing / Streaming...

[Clebert Suconic <csuconic@xxxxxxxxxx>]

> 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.

That's right.. the only thing I want is the capability of acking the receipt of a message.

I'm fine allowing the implementation to decide how messages are distributed between multiple consumers (errr... lets call it endpoints for now)... we just need to allow such things in the API and refer to the implementation about the semantics.

The leaner we keep it (in terms of semantics requirements), the better.

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

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