From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============9056039582192499969==" MIME-Version: 1.0 From: Walker, Benjamin Subject: Re: [SPDK] About dump/load (or export/edit/import) JSON file by SPDK Date: Fri, 02 Feb 2018 17:48:33 +0000 Message-ID: <1517593711.2371.30.camel@intel.com> In-Reply-To: 6c5f58f0-0dec-b9d8-c8e5-38f17dadeb38@intel.com List-ID: To: spdk@lists.01.org --===============9056039582192499969== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Fri, 2018-02-02 at 10:24 -0700, Daniel Verkamp wrote: > I agree that we definitely want to be able to have comments in the > configuration file. > = > We already have support for (non-standard) JavaScript-style // and /* */ > comments in our JSON parser; it just needs to be enabled with the > SPDK_JSON_PARSE_FLAG_ALLOW_COMMENTS flag. > = > However, if we make the config file parser an external Python tool, we wo= uld > probably need something like JSON-minify to remove the comments first (or= a > JSON parser that has non-standard comment support). I think the top level object should be a JSON list which contains the alrea= dy- defined RPC calls. The 'id' and 'jsonrpc' fields can be omitted and automatically inserted by the config file parser. JavaScript-style comments should be allowed, which can be removed using JSON-minify. I'm glad this is= the consensus that's emerging - it should make this really easy to use. > I like the idea of having an external tool (possibly written in Python) t= hat > loads the JSON config file and sends RPC requests one at a time through t= he > existing JSON-RPC interface; that keeps the SPDK library code modificatio= ns to > a minimum. I agree with this one. Let's just write a simple Python script that loads t= he config file (json.loads), then iterates through the list of RPC commands and sends them one by one using the regular interface. On Fri, 2018-02-02 at 01:22 +0000, =E6=9D=BE=E6=9C=AC=E5=91=A8=E5=B9=B3 / M= ATSUMOTO=EF=BC=8CSHUUHEI wrote: > We should keep the current config file implementation for compatibility? > Or is it OK to replace the whole to the new one once everything is prepar= ed? We need to have some level of backward compatibility, at least for a full release cycle, in my opinion. I see two options: 1) Leave the current config file parsing in our code. Add the ability to du= mp JSON-RPC config files in response to SIGUSR (which is planned anyway). If t= he user passes a config file on the command line, print out a big deprecation warning, but otherwise continue. This gives users the ability to load up th= eir old configuration file, then dump the new JSON-RPC format. After a release cycle, we can delete support for parsing the old config file. At that point= , if someone needs to use an old config file they can always go back to the rele= ase that supported both formats and use it as a converter. 2) Write a Python script that converts the old config format into the new J= SON format. This allows us to delete the current config parsing code immediatel= y and provide the conversion utility with every release going forward. My only co= ncern with this approach is it may not be trivial to do the conversion, but I cou= ld be wrong. --===============9056039582192499969==--