.red as file extension for Node-RED flows

Core Development
,
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
21

My comment was specifically referring the to the extension not the effort - I imagine that the effort is not ephemeralizable but as there are many things to be done - including picking an extension name - there is no reason not to do them in parallel if no clear dependency exists.

Why not have a discussion concerning the extension naming, let everyone involved be aware that the discussion might be pointless since the effort won't be made to make the change. Personally I'm good with that.

22

Nick echos my (less well formed) words. My earlier musings were future thinking, but we should not forget the underbelly of the beast.

To add to my earlier thoughts - perhaps kick start a specification?

NOTE: where I say NR V4 - I mean a future node-red version (beyond V3.1.x not necessarily V4)

My personal thoughts regarding change to file ext + changes to flow file are along the lines of:

  1. NR V4+ Export has a "legacy export" option (exports original flow array)
  2. NR V4+ Default file ext becomes .nrflow (or whatever the popular choice is)
    2a. This means NR instantly recognises + expects the flow file format to be the new format
    2b. This does NOT mean NR V4+ will not load an earlier JSON flow file
  3. The new format is still JSON but the flow is embedded
    3a. The overall structure would be extensible (i.e. top level object) with well formed (schema backed) arrangement
    3b. The Flow would be a sub property of the new structure (i.e. .flow)
    3c. Version information would be captured and placed as a sibling property to .flow so that faithful recreation / import of flows could be realised (i.e. upon importing a flow, if you have Dashboard V3 and the flow was exported with dashboard v4 - you would be wwarnd & given the oppotunity to update your nodes)
    3d. Future additions (e.g. meta type data) would be placed in a well known property
    3e. and so on
  4. The embedded .flow MUST be backwards compatible (Array of objects) - permitting simple extraction for older NR versions.

Bonus Points:

  1. A NR plugin is developed for NR < V4.x that understands how to extract the flow from a .nrflow

This is by no means exhaustive and the mount of work to achieve this (or similar) would need to to be carefully weighed - however, a specification has to start somewhere!

1 Like
23

That is true - we can separate the discussion of a new flow file format, and whether the filename extension should change.

Although a introducing a new extension would be an opportunity to change the format inside the file as the extension helps distinguish the two.

4 Likes
24

I'm thinking there is a difference between exporting/importing a flow and cutting and pasting a few nodes to the forum to ask for help or indeed when editing. When exporting it would be nice to have all the richness that could be included - but when cutting/pasting I possibly don't want to expose all my settings and other metadata for the world to see. (and indeed for it to then have to resolved/deconflicted wherever and for whomever pastes it into their editor).

Lot's of pre-thinking required before this task is undertaken I think.

1 Like
25

Good point :thinking:

I guess that could be partially caught by the difference in Json: is it an array or is it an object? Object contains the flows attribute which is the node array in addition to more meta data.

I would assume that import/export functionality would continue to export arrays if a sub-flow or subset of nodes is selected but in fact, even if an entire flow (i.e. a tab not the entire flow.json) is selected. The import would accept either an array or an hash object and decide what to do accordingly.

Of course this could be seen as being fragile since it depends on types (array v. object) but then again, what isn't made of silicon atoms?

Btw what is wrong with the current format (sorry for the laziness if this clear somewhere else ;))

26

Very good point Dave. Tho I suspect sometimes, you would want this - or rather a part of it (for issues like when you are exporting a flow that works perfectly with node-red-node-mysql and the user has the nameclash version node-red-contrib-mysql installed

Without a doubt Dave - your excellent point above being one such thing.

1 Like
27

The current format is not entirely (or rather: easily) extensible. Being an array of objects, each element MUST equate to an installed node. Therefore, if you want meta data (e.g. like which contrib nodes this flow uses) there is no way to add this to the flow without adding a suitable matching node that understands the object properties. See my response to Dave above

Also, there have been some good ideas requested over the years that have kinda died off due to there being is "no way to save that in the flow" (paraphrasing).

So to try and clarify my personal standpoint on the overall subject: If we were to choose an alternative file name extension, it would be with good thought and a fully spec'd rejig of the flow file format - with a published and versioned JSON schema that permits future possibilities through extensibility.

1 Like