Adopting a dedicated cadnano file extension

[scholer]

Currently, cadnano uses ".json" as file extension for cadnano files. This makes sense, since the cadnano files are JSON formatted. However, .json is a generic file extension, which is used by many applications to store many different kinds of data - including configuration files. Using a generic file extension has some drawbacks, primarily that it isn't possible to easily identify cadnano files from other json files. This makes it harder to search for cadnano files with Spotlight or other search tools. And since not all json files are cadnano files, users generally wouldn't want to associate json files with cadnano, but rather have a text editor be the default application to open generic json files. It would be nice to be able to open a cadnano file with cadnano simply by selecting it in Spotlight or by double-clicking it in Finder.

In addition to ".json", the documentcontroller code already has references to two other file extensions, ".nno" and ".c25". The ".c25" extension appears dedicated to a particular version. It is not clear to users if ".nno" is intended as an official file extension to be used instead of .json, or if it is a special file extension with a purpose different from regular .json files. In any case, I've never seen any users actually use any other file extension than ".json" for their cadnano files.

Proposal: Use a dedicated file extension for cadnano files.

I've personally started to use ".cnjson" as file extension for my cadnano files. It makes it easy to search for cadnano files, and I can associate that file extension with cadnano to open cadnano files in cadnano by selecting them in Spotlight or double-clicking them in Finder/Explorer. The .cnjson also looks enough like the old .json extension that people can recognize the file as a "cadnano json" file.

Discussion:

What is the right file extension to use with a file? – One objection against using a different file extension might be that "cadnano data is just json-formatted text, which is usually stored with .json file extension". However, just because a file is using a generic data/file format does not mean that it has to use a generic extension. For example, a word document is just a zip file with xml files inside. Yet, it would be very awkward for users if word files had a .zip extension rather than .docx. Many other applications also use generic file formats (both binary and text) for their data, but have a dedicated file extension so files can easily be identified and opened in the correct app.

Another objection might be that up until now, cadnano has used .json as file extension, and changing it may confuse users. Application development should be somewhat conservative and not deliberately break things for the user. In our case, I don't think we would break anything for the user, since .json is a generic extension. Users may be confused initially if they expect .json as file extension. This is why I've opted for .cnjson as extension. But I think users would adapt rather quickly to any extension, e.g. .nno—as long as it is used consistently.

A final objection might be that "users are already free to use whichever file extension they want for cadnano files!". While this may be true, I've never actually seen any users other than myself using alternative file extensions for their cadnano files. Everyone uses .json, because it is the defacto standard chosen by the cadnano application. Cadnano files are emailed back and forth and otherwise shared and opened by many people, so having a single standard file extension is optimal to reduce confusion.

[sdouglas]

Thanks @scholer for your detailed & thoughtful submission. When I picked .json over a decade ago I wasn't aware of any other applications that were using it, but as you point out, its popularity has grown over time and it would be good to use something unique. As you found in the doc controller, we've already thought about this a bit, but haven't quite settled on an ideal extension, so thanks for the .cnjson suggestion. Additionally, @nickfong has been exploring the use of git repos as a means to store designs with built-in version histories and non-json data.