[ArchBoard] Rename dequeueMessages to receiveMessages, enqueueMessage to sendMessages. Return with the suffix item

[sima-zhu]

No description provided.

[tg-msft]

The proposal is to change DequeueMessages to GetMessages or possibly ReceiveMessages (which aligns more with EventHubs)?

Would there be a similar change from EnqueueMessage to AddMessage?

[sima-zhu]

@rickle-msft
Xstore team suggested to have a more general strategy for all get/set APIs
(e.g. enqueue/dequeue, get/setProperties, get/setAccessPolicies)

[rakshith91]

Note: This is called as recieve_messages in Python.

[HarshaNalluru]

In JS, I'm inclined to go with some variant of "receive messages" instead of "dequeue" similar to servicebus and eventhubs.
Need to discuss with Storage JS team.

[kurtzeborn]

The naming in the REST endpoint is "getMessages" so that aligns with this suggestion. XStore team agrees with using getMessages instead of dequeueMessages.

Concern: it might be confusing/unexpected to developers that this makes a REST call if it's named getMessages (which they might assume is only accessing local data).

@JonathanGiles, what do you think about this?

[JonathanGiles]

The Java team is trending towards a naming convention where local operations drop any prefix, e.g. 'get', 'is', 'set' will not be present. Remote operations on the service client class would be the only place where prefixes would be used, and they would continue to be named as appropriate for the operation - in this case 'getMessages'. Even if we don't make this change, the proposal to use 'get' for a remote operation is fine with me.

[rickle-msft]

I'm fine with get/set for remote operations if local operations don't have a prefix (which is a change from what Storage currently has iirc).

If local operations do also use get/set, then piggy-backing on what Scott mentioned, my concern with remote operations sharing get/set with local operations is that until now, our remote operations returned Response whereas now many of them return just T. So previously it should have been clear based on the return type wether getX was remote or local, but with just T, it really only furthers the confusion.

[alzimmermsft]

@tg-msft @rickle-msft @rakshith91 @HarshaNalluru

Have we reached an agreement on whether we want to move forward with this renaming? Otherwise I propose we close on this issue.

[tg-msft]

We're about to start the next major round of API reviews. Let's all add this suggestion in the QueueClient APIs and let everyone hash it out there.

[sima-zhu]

Working on it.

[joshfree]

@sima-zhu can you update the title / issue content with the actual change now being tracked (given this issue is now 3 months old and contains a couple variations of the evolved thinking in API naming here)