eclipse / paho.mqtt.javascript

paho.mqtt.javascript
Other
1.15k stars 467 forks source link

API uses non-standard names like "send" and "destinationName" #10

Closed jpwsutton closed 8 years ago

jpwsutton commented 8 years ago

migrated from Bugzilla #440771 status UNCONFIRMED severity normal in component MQTT-JS for 1.1 Reported in version 1.0 on platform All Assigned to: Andrew Banks

On 2014-07-30 09:09:39 -0400, Karl Palsson wrote:

Every other MQTT library uses "publish" to publish messages, and "topic" for the topic. It's rather odd to find "send" and "destinationName" used in this library instead.

Seeing as any semblance of backwards compatibility was already broken, it would be a major improvement to make this more in line with every other user and library.

On 2014-08-11 04:01:07 -0400, Ian Craggs wrote:

Karl,

"Seeing as any semblance of backwards compatibility was already broken". What do you mean by this? Backwards compatibility with what?

The async C API uses sendMessage as the operation to publish.

On 2014-08-11 05:55:37 -0400, Karl Palsson wrote:

Backwards compatibility with prior releases of the javascript code. compatibility with the C api is not "backwards" compatibility, it's sideways at best, and if I was using the C api you mention, would have filed the same bug there :)

On 2014-08-11 06:10:45 -0400, Ian Craggs wrote:

(In reply to Karl Palsson from comment # 2)

Backwards compatibility with prior releases of the javascript code. compatibility with the C api is not "backwards" compatibility, it's sideways at best, and if I was using the C api you mention, would have filed the same bug there :)

I just mentioned the C API as an example of an alternative function name, not as a base for backward compatibility.

I was not aware that this Javascript API had changed in an incompatible way. I thought that this API has always used "send" and "destinationName". I just checked the initial commit of the code, which appears to verify that.

On 2014-08-11 08:06:33 -0400, Karl Palsson wrote:

Yes, the method names stayed, but the package changed. You were required to modify your code if you moved up to v1.0, hence, backwards compatibility was lost, so let's take advantage of that.

Messaging -> Paho.MQTT and there were some parameters to functions changed. I don't have them all to hand right now.

On 2014-08-13 05:40:11 -0400, Ian Craggs wrote:

Unfortunately, yes the package name did change. I felt we had to bite the bullet on that one - it had been dithered about for long enough, and we were going for version 1.0.

I'm not aware of function parameters changing, though. So I feel your statement "Seeing as any semblance of backwards compatibility was already broken" is an exaggeration.

As we have released 1.0 now, we can't just throw in more incompatible changes without changing the version number. We could however add synonyms for the current APIs, at the expense of code complexity and size.

The reason why the author used send and destinationName rather than publish and topic, is as you might have guessed, because he was thinking about the time when these APIs might be used for queues as well as topics. I can understand both points of view.

No one else has been too exercised about these "non-standard" names though (or at least has spoken up) - they are just names.

On 2015-09-08 11:28:58 -0400, Jan-Piet Mens wrote:

The Paho Python package uses "topic" and "publish". The Eclipse Mosquitto library also. When is the Paho JavaScript library going to add compatible names? I'm asking again, because this just bit somebody who had to read through the source of mqttws31.js to find out what to do.

jpwsutton commented 8 years ago

Adding Synonyms might be the best solution here, we could add these in the next service release.

jpwsutton commented 8 years ago

Fixed in PR #85