Discrepency between HTTP and CoAP Server Configuration

[egekorkan]

When creating an HTTP server, the constructor expects an object with parameters like port, e.g. new HttpServer({port:8081}). However, CoAP expects each parameter as an argument, e.g. new CoapServer(port=5684). In the CLI, everything is an object as expected. I think that two configurations should be aligned and ideally an object makes more sense so that it looks similar to CLI configuration.

Note: When I provide an object to CoAP constructor, there are no complaints and the default port is used. For the HTTP, if I provide an argument that is not an object, I get an error.

[egekorkan]

Btw fixing this for CoAP and/or HTTP would be a breaking change and CoAP seems to have had this config for a very long time (v 0.7.0 Snapshot 5 at least)

[relu91]

Btw fixing this for CoAP and/or HTTP would be a breaking change and CoAP seems to have had this config for a very long time (v 0.7.0 Snapshot 5 at least)

This could mean that we move to 0.9.0, because is a change in the API from a user perspective. I'm totally fine with it, but maybe let's discuss it with @danielpeintner when he is back :).

[relu91]

btw technically also #1027 might be considered a change in the API as well, but it is backward compatible.

[danielpeintner]

Btw fixing this for CoAP and/or HTTP would be a breaking change and CoAP seems to have had this config for a very long time (v 0.7.0 Snapshot 5 at least)

This could mean that we move to 0.9.0, because is a change in the API from a user perspective. I'm totally fine with it, but maybe let's discuss it with @danielpeintner when he is back :).

I suggest to postpone this change for the next 0.9.0 release which (I think) should come with the changes planned in the scripting API (see https://github.com/w3c/wot-scripting-api/labels/API-improvement and/or https://github.com/w3c/wot-scripting-api/labels/for%20next%20iteration)

for example w3c/wot-scripting-api#409

Does that make sense? Or do people think that this is too far in the future?

[egekorkan]

Waiting is fine from my pov. It would be good to label such changes in node-wot as well

[danielpeintner]

Waiting is fine from my pov. It would be good to label such changes in node-wot as well

what about a "breaking-change" label ?

[egekorkan]

Waiting is fine from my pov. It would be good to label such changes in node-wot as well

what about a "breaking-change" label ?

That is fine (and should be done) but we should use for the cases where we agree on the change but going to do yet.

[relu91]

I suggest to postpone this change for the next 0.9.0 release which (I think) should come with the changes planned in the scripting API (see https://github.com/w3c/wot-scripting-api/labels/API-improvement and/or https://github.com/w3c/wot-scripting-api/labels/for%20next%20iteration)

for example w3c/wot-scripting-api#409

Does that make sense? Or do people think that this is too far in the future?

Given the fact that we canceled the subsequent two calls and August will probably be silent too, this means postponing all the possible breaking changes to September at minimum. However, considering the discussion points in w3c/wot-scripting-api#409 and other open issues I don't really believe that we are going to settle the discussion in just a couple of meetings. In practice, this means constraining the breaking of changes contributions for about 4 months.

I would like to have a leaner approach and release 0.9.x wherever it makes sense. Or if you think is not good for "marketing" we could break semver (somebody can argue that we are not really following semver anyway) but still accept breaking changes PRs and release a 0.8.x. The important point is not to stop contributions :)

[danielpeintner]

At the moment our versioning is somewhat aligned with https://www.npmjs.com/package/wot-typescript-definitions.

IF we are ok with giving up this "relation" I am also okay with releasing node-wot 0.9.x sooner.