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 would
> 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 already-
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) that
> loads the JSON config file and sends RPC requests one at a time through the
> existing JSON-RPC interface; that keeps the SPDK library code modifications to
> a minimum.

I agree with this one. Let's just write a simple Python script that loads the
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, 松本周平 / MATSUMOTO，SHUUHEI 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 prepared?

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 dump
JSON-RPC config files in response to SIGUSR (which is planned anyway). If the
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 their
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 release
that supported both formats and use it as a converter.

2) Write a Python script that converts the old config format into the new JSON
format. This allows us to delete the current config parsing code immediately and
provide the conversion utility with every release going forward. My only concern
with this approach is it may not be trivial to do the conversion, but I could be
wrong.