.red as file extension for Node-RED flows

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

Its best to keep the .json extension, as most editors recognize it.

If you want to specifically recognize it, change it to flows.red.json. This way it will be still recognizable as generic JSON and more specifically as Node-Red extension,

1 Like
29

Here I would like to quote my .emacs file:

(setq auto-mode-alist
      (append '(("\\.C$"     . c++-mode)
                ("\\.cc$"    . c++-mode)
                ("\\.hh$"    . c++-mode)
                ("\\.th$"    . c++-mode)
                ("\\.cpp$"   . c++-mode)
                ("\\.h$"     . c++-mode)
                ("\\.html?$" . html-mode)
                ("\\.c$"     . c-mode)
                ("\\.ck$"    . chuck-mode)
                ("^\\.env$"  . dotenv-mode)
                ("\\.j$"     . objj-mode)
                ("\\.java$"  . java-mode)
                ("\\.js$"    . web-mode)
                ("\\.json$"  . js2-mode)
                ("\\.jsx$"   . rjsx-mode)
                ("\\.jsp$"   . html-mode)
                ("\\.jad$"   . java-mode) ;; .jad --> Java Decompiler
                ("\\.gemspec$" . ruby-mode)
                ("\\.g?awk$" . awk-mode)
                ("\\.inc$"   . php-mode) ;; .inc --> include files in PHP
                ("\\.mhtml$" . mhtml-mode)
                ("\\.md$"    . markdown-mode)
                ("\\.php3?$" . php-mode)
                ("\\.pkg$"   . sql-mode)
                ("\\.pkb$"   . sql-mode)
                ("\\.pp$"    . puppet-mode)
                ("\\.properties$"  . property-mode)
                ("\\.pic$"   . picture-mode)
                ("\\.py$"    . python-mode)
                ("\\.py3$"   . python-mode)
                ("\\.ru$"    . ruby-mode)
                ("\\.rdfs?$" . nxml-mode)
                ("\\.xml$"   . nxml-mode)
                ("\\.ya?ml$" . yaml-mode)
                ("Jakefile"  . js2-mode)
                ("\\.hulk$"  . mustache-mode)
                ("\\.pug$"   . jade-mode)
                ("\\.jade$"  . jade-mode)
                ("\\.scd$"   . sclang-mode)
                ("\\.phtml\\'"     . web-mode)
                ("\\.tpl\\.php\\'" . web-mode)
                ("\\.[agj]sp\\'"   . web-mode)
                ("\\.as[cp]x\\'"   . web-mode)
                ("\\.erb\\'"       . web-mode)
                ("\\.mustache\\'"  . web-mode)
                ("\\.djhtml\\'"    . web-mode)
                )
              auto-mode-alist))

A good editor allows one to set the mode according to the extension. I would definitely not see that as an argument - sorry :slight_smile:

2 Likes
30

My first two cents in a NR discussion ā€¦

A .cpp file is in fact a .text file but the extention makes it clear itā€™s a special kind of text file. I donā€™t see why all json files should have a .json extention.

As stated, a .red file is a .json file but the special extention might not only make clear itā€™s a file used by / originating from node red; it might contain extra data such as (also as already stated) used nodes in this flow, a bit like how platformio.ini shows the used libraries and version in a project.

31

Sorry if this comes over as snarky but perhaps I'm missing something.

Currently Node-red works fine (on my Linux machine) if the flows file is called flows.json, flows.red or even DRINK_ME.

I find it hard to believe it's impossible to add extra data to a JSON file without maintaining backwards compatibility.

So it seems to come down to this: If the filename changes from flows.json to flows.red, it will become possible in a GUI based OS to double click on the file and run Node-red or some other flow file viewer application.

WIll flows.json become forbidden? Will DRINK_ME?
WIll the .red file use a different markup language? Which one?

While we wait for this big step forward can I suggest a work-around which might need less code changes: Right click and Open With.

32

No & no

No

It isn't impossible but there are technical difficulties that can be better solved with a slight rejig. Read my earlier post for why.

That is only a side benefit. Having a distinct name is really just a nice to have with a few benefits.: Some of these are- Recognition/familiarity & a clean way of differentiating a new file format

1 Like
33

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.