starred/s3fs-fuse

Fork 0

mirror of https://github.com/s3fs-fuse/s3fs-fuse.git synced 2026-04-25 13:26:00 +03:00

[GH-ISSUE #685] Consider using jsoncpp #385

New issue

Closed

opened 2026-03-04 01:45:02 +03:00 by kerem · 7 comments

kerem commented

2026-03-04 01:45:02 +03:00

Owner

Originally created by @ggtakec on GitHub (Nov 22, 2017).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/685

Additional Information

Version of s3fs being used (s3fs --version) - current master branch
Version of fuse being used (pkg-config --modversion fuse) - n/a
System information (uname -a) - n/a
Distro (cat /etc/issue) - n/a

Details about issue

Issue(PR) #669 #678 #682 is related

Adding jsoncpp is the best way to analyze JSON.
However, there are differences in jsoncpp's package depending on each distribution.
Analysis of JSON code for s3fs is not main, it is only a part of processing, it is limited.
Therefore, I am planning to consider a method that does not use jsoncpp (as before).

And the current code needs to be modified, but It needs C++11(Dependency is troublesome).

current codes

  Json::Value root;
  Json::Reader reader;
  if (!reader.parse(response, root)) {
    return false;
  }

should be(example)

  Json::Value root;
  Json::CharReaderBuilder rbuilder;
  Json::CharReader* reader(rbuilder.newCharReader());
  string error;
  if(!reader->parse(response, &response[strlen(response)], &root, &error)){
    delete reader;
    return false;
  }
  ...
  delete reader;

I'm checking if we can make the code simply without jsoncpp.
And please give us your opinions.

Originally created by @ggtakec on GitHub (Nov 22, 2017). Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/685 #### Additional Information - Version of s3fs being used (s3fs --version) - current master branch - Version of fuse being used (pkg-config --modversion fuse) - n/a - System information (uname -a) - n/a - Distro (cat /etc/issue) - n/a #### Details about issue Issue(PR) #669 #678 #682 is related Adding jsoncpp is the best way to analyze JSON. However, there are differences in jsoncpp's package depending on each distribution. Analysis of JSON code for s3fs is not main, it is only a part of processing, it is limited. Therefore, I am planning to consider a method that does not use jsoncpp (as before). And the current code needs to be modified, but It needs C++11(Dependency is troublesome). - current codes ``` Json::Value root; Json::Reader reader; if (!reader.parse(response, root)) { return false; } ``` - should be(example) ``` Json::Value root; Json::CharReaderBuilder rbuilder; Json::CharReader* reader(rbuilder.newCharReader()); string error; if(!reader->parse(response, &response[strlen(response)], &root, &error)){ delete reader; return false; } ... delete reader; ``` I'm checking if we can make the code simply without jsoncpp. And please give us your opinions.

kerem closed this issue

2026-03-04 01:45:03 +03:00

kerem commented

2026-03-04 01:45:04 +03:00

Author

Owner

@orozery commented on GitHub (Nov 22, 2017):

@ggtakec Are you suggesting we write our own Json parser, instead of using jsoncpp?

@orozery commented on GitHub (Nov 22, 2017): @ggtakec Are you suggesting we write our own Json parser, instead of using jsoncpp?

kerem commented

2026-03-04 01:45:04 +03:00

Author

Owner

@ggtakec commented on GitHub (Nov 22, 2017):

@orozery It is as a possibility.
If s3fs uses jsoncpp, consistency with OSX and other Linux distributions may not be unique, so people who build s3fs may have trouble.
Of course, I think that it is good to use jsoncpp, but I would like to consider including support.
About this, I'd be glad to give me any opinion from a broad perspective.

@ggtakec commented on GitHub (Nov 22, 2017): @orozery It is as a possibility. If s3fs uses jsoncpp, consistency with OSX and other Linux distributions may not be unique, so people who build s3fs may have trouble. Of course, I think that it is good to use jsoncpp, but I would like to consider including support. About this, I'd be glad to give me any opinion from a broad perspective.

kerem commented

2026-03-04 01:45:04 +03:00

Author

Owner

@gaul commented on GitHub (Nov 23, 2017):

@ggtakec Trying to understand the symptoms -- do you mean that older systems with jsoncpp 0.x work with C++03 and newer systems with jsoncpp 1.x require C++11? Can we just specify the older version which seems to be maintained, commits as of April 2017? Agreed that reverting to the simpler parser may cause fewer headaches.

@gaul commented on GitHub (Nov 23, 2017): @ggtakec Trying to understand the symptoms -- do you mean that older systems with jsoncpp 0.x work with C++03 and newer systems with jsoncpp 1.x require C++11? Can we just specify the older version which seems to be maintained, commits as of April 2017? Agreed that reverting to the simpler parser may cause fewer headaches.

kerem commented

2026-03-04 01:45:04 +03:00

Author

Owner

@ggtakec commented on GitHub (Nov 23, 2017):

@gaul I will organize the problem.
In the current master, the following warnings are output for osx(xcode 8.3) building.
This warning means to use the 1.y.z version of jsoncpp.

curl.cpp:1431:9: warning: 'Reader' is deprecated: Use CharReader and CharReaderBuilder instead [-Wdeprecated-declarations]

Another thing, AMI users must allow EPEL. (#682)
AMI users will need additional work for s3fs. Perhaps they may not be able to use EPEL

Next, we can change to use Json::CharReaderBuilder to avoid the above warning for xcode8.3.
However, that code change causes us to receive an error in the build of buntu, becuase there is no specification of C++11 in the build option.
(We have to fix the build options of s3fs to C++11.)

In addition, although s3fs is used in Raspberry Pi and others, it is uncertain whether it can be easily built with Raspberry Pi. (I can not confirm it now)

I thought about these problems and the challenges in their avoidance method.
jsoncpp is a lightweight and widely used library, and it is deployed in each distribution.
However, s3fs is also widely used, and I am worried that using the library will increase the difficulty level for s3fs users.

I decided to use jsoncpp at the ECS metadata endpoint(#671), but that decision was my careless mistake.
Considering the use and support range of s3fs, I think that you do not have to rely on jsoncpp now.
In particular, the parsing JSON format in s3fs is needed for only a input of simple JSON.
That is not a main feature for s3fs, and it can be implemented without relying on jsoncpp.
So now we can still build s3fs without jsoncpp.

For these reasons, I would like to restore it once, do not include jsoncpp, and want to be able to assemble s3fs.

Of course, jsoncpp is a good library, and I am interested in it personally, and I also have an intention to use it.
I will continue to expect that jsoncpp will be more easily and extensively used and widely available, and if JSON's analysis datas will increase in s3fs in the future, I would like to review the including again.

@ggtakec commented on GitHub (Nov 23, 2017): @gaul I will organize the problem. In the current master, the following warnings are output for osx(xcode 8.3) building. This warning means to use the 1.y.z version of jsoncpp. ``` curl.cpp:1431:9: warning: 'Reader' is deprecated: Use CharReader and CharReaderBuilder instead [-Wdeprecated-declarations] ``` Another thing, AMI users must allow EPEL. (#682) AMI users will need additional work for s3fs. Perhaps they may not be able to use EPEL Next, we can change to use Json::CharReaderBuilder to avoid the above warning for xcode8.3. However, that code change causes us to receive an error in the build of buntu, becuase there is no specification of C++11 in the build option. (We have to fix the build options of s3fs to C++11.) In addition, although s3fs is used in Raspberry Pi and others, it is uncertain whether it can be easily built with Raspberry Pi. (I can not confirm it now) **I thought about these problems and the challenges in their avoidance method.** jsoncpp is a lightweight and widely used library, and it is deployed in each distribution. However, s3fs is also widely used, and I am worried that using the library will increase the difficulty level for s3fs users. I decided to use jsoncpp at the ECS metadata endpoint(#671), but that decision was my careless mistake. Considering the use and support range of s3fs, I think that you do not have to rely on jsoncpp now. In particular, the parsing JSON format in s3fs is needed for only a input of simple JSON. That is not a main feature for s3fs, and it can be implemented without relying on jsoncpp. So now we can still build s3fs without jsoncpp. For these reasons, I would like to restore it once, do not include jsoncpp, and want to be able to assemble s3fs. Of course, jsoncpp is a good library, and I am interested in it personally, and I also have an intention to use it. I will continue to expect that jsoncpp will be more easily and extensively used and widely available, and if JSON's analysis datas will increase in s3fs in the future, I would like to review the including again.

kerem commented

2026-03-04 01:45:04 +03:00

Author

Owner

@orozery commented on GitHub (Nov 23, 2017):

@ggtakec Please consider #686 for resolving this issue.

@orozery commented on GitHub (Nov 23, 2017): @ggtakec Please consider #686 for resolving this issue.

kerem commented

2026-03-04 01:45:04 +03:00

Author

Owner

@ggtakec commented on GitHub (Nov 23, 2017):

@orozery Thanks, I merged your PR(#686) now.

@ggtakec commented on GitHub (Nov 23, 2017): @orozery Thanks, I merged your PR(#686) now.

kerem commented

2026-03-04 01:45:04 +03:00

Author

Owner

@ggtakec commented on GitHub (Nov 23, 2017):

I'm closing this issue, but if you have a problem, please reopen this issue.
Thanks all.

@ggtakec commented on GitHub (Nov 23, 2017): I'm closing this issue, but if you have a problem, please reopen this issue. Thanks all.

kerem referenced this issue

2026-03-04 01:54:12 +03:00

[PR #385] [MERGED] fix typo in curl.cpp: s/returing/returning/ #1488