True, the official position allows the alternative naming, but that does not affect the fact that the convention is to use node-red-contrib. The proof of whether this is in fact the convention is to look in the flows site, of the couple of thousand nodes it seems that only a handful do not follow that convention.
2 Likes
We are not living in conventional times. If it hadnāt already been published to npm I would agree, but unpublishing is a pain, and it is not a hill worth dying for. The name is fine. Letās worry about if it works.
1 Like
No, typically I just put the name into a search box in my browser. I note that your Keepass node didn't have any hits on the first page of a Startpage.com search. Having node-red in the name of the project most certainly gives helpful discoverability.
Re your Keepass node, npm doesn't list a repository for it so I couldn't raise an issue. I was going to raise one to comment on the potential security risks of that node and the fact that they are not highlighted to potential users who may not realise what they are doing with their highly sensitive data.
Phew - I didn't expect that. 
I appreciate the discussion (that's what defines a vibrant community). Anyway, I don't think this is the place for it. Let's keep this what it is - an announcement - and move the discussion to the place it belongs: into a PR to change the documentation.
If the community agrees that the official position is to only use the node-red-contrib-prefix and the documentation gets changed correspondingly, I'm happy to act accordingly.
Until then I agree with @dceejay:
In the scheme of things to worry about these days it's not top of the list.
2 Likes
@TotallyInformation I agree - the other scheme might be helpful for finding it in search engines. We will consider this in the future.
Regarding kdbx-RED: Sorry! We obviously forgot to add the repository in the package.json. We will fix that of course. Until then: It is hosted on GitLab.
I agree with you that a comment on potential security risks is necessary. I will change that as well. Thank you very much for the feedback!
well as Nick points out - you've already followed the OFFICIAL position and that's OK. Everyone else is just pointing out that convention sometimes trumps an official position for convenience.
After all, Node-RED is open source, there cannot, by definition, be hard and fast rules. But as you also say, this is a vibrant (and opinionated!) community.
2 Likes
If you would like any specific feedback, please feel free to DM me.
1 Like
To get back to the node itself: @dceejay mentioned that @knolleary might help with a best practice. If so I would be very thankful. @knolleary, do you have one for us? 
I can promise: We do our best to contribute tools to the community that are useful. Anyway, we are a small company with only two part-time developers and furthermore quite new to contributing (we were mainly consumers so far). So feedback that helps us improving our contributions are really welcome. I would just ask you to be patient with us. We are all learning. Especially in these tough times. Thanks!
1 Like
Hi Chris,
thanks for the work. Could you give me an example of the required URL when I have NR in a docker and the .yaml files is located in the docker under /data/openapi.yaml?
best regards,
Sven
Hi Sven,
you cannot access the file directly. Instead you need to serve it in some way (e.g. using the http in node, a file in node and an http response node or alternatively using pekfinger-RED's web content node). Afterwards you can access it using the URL under which it is hosted (e.g. http://localhost:1880/openapi.yaml).
Please mind that it is the server which accesses the URL and not the client!
Hope this helps.
Take care
Chris
HI Chris,
now it seems to work. I tried your recomendation with the HTTP and file in node. At the moment i get the Error "operation.tags is not iterable". I will give it a try with other encoding.
Thanks a lot.
Sven
Hi Sven,
it seems as if your openAPI definition does not define tags for its operations. We currently rely on the tags to group them on the frontend. Anyway, we are working on a fix so that operations without a tag are listed in a default group. I will post as soon as the new version is available.
Chris
1 Like
Hi Sven,
new version is online (may take some time until it gets updated in the node-lib). Operations without a tag should now be added to a default group. Could you please try again?
Chris
Hi Chris,
thank you for the quick fix.
I have tested the new version and now I get the error "Cannot read property 'constructor' of undefined".
I think I have a problem how to serve the yaml file. I can access the yaml file with my browser. That looks fine.
[{"id":"dba8b551.f69a08","type":"openApi-red","z":"8b4a9ef6.acb84","name":"CPX_API","openApiUrl":"http://localhost:1880/openapi.yaml","api":"","operation":"","operationData":{},"parameters":{},"x":140,"y":1300,"wires":[[]]},{"id":"ab124aa7.60b5a8","type":"file in","z":"8b4a9ef6.acb84","name":"read openapi.yaml","filename":"/data/CPX-IOT-S_API/openapi.yaml","format":"utf8","chunk":false,"sendError":false,"encoding":"none","x":490,"y":1360,"wires":[["ef812af0.3e02f8","ecd802cc.9aea7"]]},{"id":"f8d67abc.bef998","type":"debug","z":"8b4a9ef6.acb84","name":"","active":false,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","x":890,"y":1440,"wires":[]},{"id":"385660f5.6bea","type":"http in","z":"8b4a9ef6.acb84","name":"","url":"/openapi.yaml","method":"get","upload":false,"swaggerDoc":"","x":150,"y":1360,"wires":[["ab124aa7.60b5a8"]]},{"id":"896282d7.59163","type":"http response","z":"8b4a9ef6.acb84","name":"","statusCode":"","headers":{},"x":1050,"y":1360,"wires":[]},{"id":"ecd802cc.9aea7","type":"change","z":"8b4a9ef6.acb84","name":"Set Headers","rules":[{"t":"set","p":"headers","pt":"msg","to":"{}","tot":"json"},{"t":"set","p":"headers.content-type","pt":"msg","to":"text/yaml","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":770,"y":1360,"wires":[["896282d7.59163","f8d67abc.bef998"]]},{"id":"ef812af0.3e02f8","type":"debug","z":"8b4a9ef6.acb84","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","x":690,"y":1440,"wires":[]}]
I will continue the tests tomorrow.
best regards,
Sven
To me it doesn't sound like a problem of how the file gets served. I'd rather guess that either the file is not well-formed or our node has a problem handling a specific case (or the library we use for parsing).
If you send me a PM with the yaml-file (if that's ok for you), we might be able to investigate further. Otherwhise it's a bit hard to tell the root cause of this.
Hi Chris,
can you help me with setting the required parameters? I want to use the IO-Link REST API and operations that don't require parameters work well, but how can I set parameters of operations?
You should be able to set the parameter directly within the UI. Obviously you're not. So we have a bug here. 
Sorry for that. Will investigate on it.
Unfortunately we cannot reproduce this without the yaml-file. Could you send it to me?
BTW: Do you get an error on your console?
A new version (0.1.4) is online. If you could please try again. It should work now. 
