search

Particular / NServiceBus.Gateway

https://docs.particular.net/nservicebus/gateway/
Other
4 stars 8 forks source link

Properly name the Gateway retries configuration API #57

Open MarcinHoppe opened 8 years ago

MarcinHoppe commented 8 years ago

What is the problem?

We have recently changed the vocabulary we're using to describe recoverability actions in the core. The terms we now use are:

The Gateway has an API to configure number of retries the Gateway will make when sending message over the channel fails. The term currently used in this API is "retry".

The problem is that this term is not consistent with the vocabulary used by the core. What is more, it does not clearly state that we're configuring number of channel retransmission attempts, which is a different concern than core recoverability.

What can we do about it?

My proposal is to find a proper term to use and rename the APIs accordingly. We have 3 API calls to consider:

I think borrowing established terms from related areas of computer science may make it easier for users to understand what is actually being configured. The best term I could find is borrowed from the world of TCP/IP networking and WCF (which seems very relevant in the context of a gateway channel): retransmission. The APIs would then look like this:

@danielmarbach @andreasohlund I'd love to get your thoughts about this.

Plan of Attack

andreasohlund commented 8 years ago

I like it, using terminology that makes sense for the GW (transmitting messages btw sites) is great!

danielmarbach commented 8 years ago

I'm happy with that. Since I was the one pushing you towards it because I didn't agree with @andreasohlund before ;)

Good stuff!

MarcinHoppe commented 8 years ago

OK, I'll implement the change then. Expect the PR soon(-ish).

MarcinHoppe commented 8 years ago

@Particular/nservicebus-maintainers Do you feel we need to have it for NSB v6 / NSB.GW v2 or we can postpone this for NSB.GW v3?

andreasohlund commented 8 years ago

I vote for GW v3, lets focus on the upcoming RC instead?

MarcinHoppe commented 8 years ago

I'm OK with that. Let's wait for @danielmarbach to chime in because he was concerned with API inconsistencies the most. I attach it to the brand new 3.0.0 milestone to make it easier to track.

danielmarbach commented 8 years ago

I'm all for scoping down work which is not really required. Here it seems we have an agreed upon proposal which seems only API changes. Why not now since we already dove into it?