.red as file extension for Node-RED flows

Core Development
,
1

Not sure in which category I should put this. It's not really a feature request. More like a request to define a standard.

The flow files do have .json extension by default (which is rather generic). It would be useful if there was a Node-RED specific file extension such as .red (or something that does not exist yet). This would make it easier for file management systems to identify flows.

2 Likes
2

As a workaround you can set the flow name on your setting file and/or use any Filename you like. Renaming it may mean other tools don’t accept it but how often do we use those :wink:

3

Reading my post again. Maybe I was not clear enough. It would be great if, per default (out of the box), the flows would not be named as flows.json anymore. Instead, Node-RED would use a more or less unique extension such as .red, .nr or .nick, you name it.

1 Like
4

Do you also wish to change the "extension" on settings.js?
What about such files as .node-red/context/global/global.json?

Since my Node-red runs on command line only Linux, there is no such thing as a file extension and the only "file management system" I have is the file command, but it is smart enough not to classify the contents based on the file name.

$ cp flows.json thisIsMyFlowsFile.cpp
$ file thisIsMyFlowsFile.cpp
thisIsMyFlowsFile.cpp: JSON data

What are these file management systems which do classify based on filename?

5

Well I think it's efficient as a first guess of the format. Whether or not it is really what it "pretends" to be should be handled by the linked application.

The fact that you used .cpp makes it quite clear how important extensions are. You immediately assume that it is C++, because we are so used to it. Plus filtering is fast and easy (cause you don't have to check the content in the first step).

Anyway, this is not a feature I need desperately, but it would help to identify Node-RED flows in our cloud system and link them to a flow viewer application. And instead of using a special file extension internally only, I thought others could benefit from this, maybe.

6

Another option might be to allow for a schema definition reference in the json file.

Personally, I believe that the flow files should stay as .json which is, after all, what it is. But a schema definition property in the file might be useful.

1 Like
7

Would there be an additional block in the json File? Is there a feature request regarding this?

This would still mean that you would have to read and parse all json files first, before creating flow previews (for example).

1 Like
8

What are you trying to solve ? The flows file is a json file, hence the extension.
You could check if an key exists like "wires" or an object type like 'debug' or just specific texts that "would" exist in your flows.

example
cat flows.json | jq 'map(has("wires"))'

9

Yes, though you wouldn't really ned to parse it as @backman2 suggests.

The potential advantage though would be the ability to have a published schema for flow files.

JSON Schema | The home of JSON Schema (json-schema.org)

Which would facilitate external use and validation.

2 Likes
10

I see the .red approach as a pre-filter and validation should be done later on a smaller set of files / candidates.

.docx isn't called .xml or .zip for a reason.

I don't know how to sell the idea :pensive:

1 Like
11

Well docx is a zipped collection of files. Not a single XML file. And we can't account for Microsoft's marketing department who tend to set the tone for those things. :slight_smile:

In addition, Microsoft have sufficient market size that other vendors are forced to adopt the file type.

I think we all get the idea and there is certainly some merit in it. But the question is whether the benefits outweigh the issues.

Benefits

  • Obvious what files are Node-RED flow files - though it is generally already pretty obvious in most cases due to the folder it is in and its name.

Dis-benefits

  • Requires significant rework to Node-RED.
  • NR Would still have to support .json files for backwards compatibility.
  • When wanting/needing to edit the flow using another tool, the tool would not recognise its file type.
12

I disagree with all the listed disbenefits

  • Requires significant rework to Node-RED. The settings file which is shipped with a fresh installation would contain flows.red (just an example) instead of flows.json and when exporting flows, the new extension should be suggested (instead of .json). I am sure there are other changes needed. But are there any significant ones?

  • NR would still have to support .json files for backward compatibility. I can already name the flow file whatever I want to and the new standard won't break anything. I might be wrong though.

  • When wanting/needing to edit the flow using another tool, the tool would not recognise its file type. With time those tools will. Until then you can manually change file associations.

Benefits

  • Easily identify Node-RED flows (candidates).
  • Yes, it's a marketing thing. The Node-RED project deserves a catchy file extension.
  • I give up already :rofl:
2 Likes
13

I see this a bit like having .ipynb extension for Jupyter notebooks. if you look inside they are a big fat json, so they could also be called .json but they're not. The benefit is that GitHub, seeing the ipynb extension, creates a preview of that same json file.

If there was a .nrjson or .jnrflow extension, GitHub could do the same with Node-RED flows.

Both formats have something in common: they are visual, so they should be presented visually. My beef against the "one long line of json" is not unheard of so I might be biased.

Also also my editor would be happy since I would map the extenstion to fundamental-mode instead of having it parse a 1.3MB long json string because the json-mode kicks in for .json files.

3 Likes
14

I love the idea!
When now Node-RED is approaching more to industrial usage having the files named .red would make sense just from the user experience! And also the point that gregorius is making is very strong (from my subjective perspective).

In industry the more clearer and straight things are - the better!
Now if you look at any .json file it could be a Node-RED flow.

But .red would be right away clear to everyone that it is a Node-RED flow.

+1 from me!

15

Thanks for the +1. Yes, I do believe too that it would be a clear and strong label.

1 Like
16

Time to chime in. (Disclaimer at the end)

I was initially not in favour of this proposal but I now admit I can see some merit.

I think where it might be considered is if/when the flow file format needs a version bump (for say new features or storing meta data - see below) but my theory is that an extension change could go hand in hand with identifying a newer flow file format. We could even continue to support the original .json files for backwards compatibility.

Re: meta data. If flow files could store information like which contrib nodes are used, flow settings, potential future stuff like vertical flow option/tab colours/tab grouping etc, and more new possibilities open up. The flow file format is currently an array of objects & and each object is a node (a simplification but good enough for now) and therefore meta data is not something that can be added in a backwards compatible manner. However, if we started using a different file extension, the new format would be instantly recognisable to users and the node-red runtime as being a newer v4 file (or v5 or which ever version of Node-RED embarks on that new direction)

Additionally, like most applications do, there is a future where I see a .flow file (or whatever it is called) could be loaded by extension & start running simply by association (e.g like how you double click a txt file and the os knows which application to use)

Disclaimer: these are my own thoughts and don't necessarily reflect those of any of the Node-RED maintainers. But hopefully some of the stuff I've spilled out of my head forms other ideas & sparks more discussion until a clear direction and speciation are formed. Or not!

4 Likes
17

added in a backwards compatible manner.

One possibility would to have a hash format for the next version. Then the editor would load the json (it would remain json under the hood I presume) and if it's an array then version 2 or lower, if hash then version X (whatever version would begin with the hash) with meta data components...

1 Like
18

We could even continue to support the original .json files for backwards compatibility.

This is a crucial point and exactly something we would need!
The new Node-RED would still support .json files but every export from now on would only create .red files.

And somewhere in the far future there would be only .red files :smiley:

19

I won't disguise my preference for something more specific than .red as extension, checking wikipedia for existing extensions and .red is indeed free even though there is a .r3d extension.

I would go for something like .nrj - node-red json (although that's a radio station - but it is meant to mean energy!) - I find .red too generic.

But that's me and I guess the most important thing is to find an extension (ideally 3 characters) that is free and that makes an immediate connection to its purpose - .exe execution, .png (Papua New Guinea) image, .svg scalable vector graphic, .jpg (json + postgres?) image ... are all bad examples unless you happen to be a techie (remember: execution has a different meaning for different people!)

1 Like
20

But that's me and I guess the most important thing is to find an extension (ideally 3 characters) that is free and that makes an immediate connection to its purpose

Well, first we need to decide if this whole effort is something the project wants to take on, before lots of decisions are made without any connection to the actual work that has to happen to make it a reality.

Modifying the flow file format is a huge undertaking. As soon as the editor starts exporting something different to what it does today, you break backward compatibility. You end up with 'flows' that technically will run fine on older versions of Node-RED, but that are incompatible due to changed format.

Whilst its easy to imagine all the new things it would enable, the hard work is minimise any disruption it brings. That cannot be shrugged off - it has to be addressed first.

2 Likes