Add utility methods for startLRA and joinLRA not containing timeout parameters

[xstefank]

Posting this as a question to the community. There is an idea to add overloaded variants of startLRA and joinLRA methods that do not contain timelimit and time unit parameters that would mean that by the default no timeout should be used. Such methods can help with repetitive unnecessary attributes in the user code, but on the other hand will make the client API more complex. There is a reasonable trade-off so we would like to ask for the opinion in the community.

[xstefank]

A side note a LRAManagement interface already contains such utility method without timeout for the joinLRA case

[tomjenkinson]

I think we should remove joinLRA from the LRAClient api then

[xstefank]

@tomjenkinson sorry I don't understand what you mean, joinLRA in LRAClient is required for programmatic API.

To the original question, I think the added complexity which would be introduced by these usability methods can be removed by default implementations in the LRAClient interface and the benefit for the end users can be very valuable as timeouts are just not necessary every time.

I also checked other MP specifications and there is no similar example of such extensive interface, but if you prefer we can still take this conversation to the MP mailing list.

[ochaloup]

Tjos sounds as a good idea to me. It's a pleasant UX benefit.
The need to write the timeout for each API call is pretty boresome from user perspective. It's a good practice to provide a way to call the function without default valued parameters being required.
Currently the user has to search for default timeout value to pass it to the methods even he does not care about timeout at all.

[mmusgrov]

Note that we should be encouraging the use of annotations over the programmatic API.

[ochaloup]

I think encouraging annotations has nothing in common with fact to make our API nice to use.

[mmusgrov]

Adding too many utility methods just makes the interface noisy, but if that's what people want.

[ochaloup]

I would argue it's usual way to make the AP not noisy but easier to use. It's way to help the user. But I agree this could be matter of taste. You can check e.g. java APIs String, StringBuffer all the functional of(...) methods etc.

[mmusgrov]

+1

@xstefank it looks like you have a +3 on this issue which is enough to go ahead with a PR (and we don't need to go to the MP mailing list).