-
Notifications
You must be signed in to change notification settings - Fork 225
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add nojsonrpc qmake CONFIG option #2660
Add nojsonrpc qmake CONFIG option #2660
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally, I'm not too convinced whether the additional logic is worth the benefits.
Avoids potential issues with JSON-RPC. Also keeps the builds faster and smaller (
headless serveronly nojsonrpc
is 2.2M, a full build is 3.4M).
I'd argue that a runtime-disabled JSON-RPC interface should be equally issue-safe.
Is the 1.2M binary difference solely due to nojsonrpc
though? If so, that'd certainly convince me, but I suspect that most of it comes from the disabling of client code and client dependencies.
There's almost no logic involved. The benefit is more in terms of control over what's in the build. I don't want RPC (currently). I might never want it in my server and directory builds. Also, given that concerns (#2614) over it have been raised, I think the benefits are there. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the free extra was an individual commit that had a Fixes: #2574
that would be even nicer... :)
It does appear to :)
|
d0167e7
to
37d58b8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I find some time, I‘ll test it
37d58b8
to
10bdc8f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok. Thanks. It works. Wouldn't we want to exit with an error code (exit(1)) if an unsupported cli option is given?
It's all a bit hit and miss currently. Some do, some don't. If you run the server build and don't say So for JSON-RPC, if you ask for it in a non-JSON-RPC build, well, it's just ignored - but not silently. For the options that only apply in certain modes, checking was inconsistent... |
I think from the user point of view, there's a difference between forgetting an option (-s) from a specialised build (=serveronly) (which is predictably an user error but we can predict what is wanted) or adding an option which we cannot assume to be "default on" like some jsonrpc option to a non jsonrpc enabled build (we can assume the user explicitly requested it but the option is disabled during compiling). But it's certainly debatable. |
@pljones I added "if requested" to the changelog entry. |
It seems redundant to me. All the config options need to be requested. |
Then maybe turn it around: Users can disable JSON-RPC by adding the nojsonrpc CONFIG option during build time |
That doesn't follow the style guide for the ChangeLog. It's meant to be a (brief) past tense statement of what's changed in the code base.
|
Hmm. I don’t think we have a style guide for the ChangeLog yet. My thought is that the changelog is a place for brief description and documentation for users (who might not know the Code but have some technical background). So the question is: What does the user need to know about this change? What can he do now? I think your suggestion is still OK. |
Mmm, the Pull Request template says |
As I said, I'm ok with your suggestion |
Short description of changes
JSON-RPC is introduced with Jamulus 3.9.0 in an initial form. As some potential problems may arise, having a build option to omit it gives the flexibility to (hopefully) avoid such problems.
CHANGELOG: Add nojsonrpc qmake CONFIG option to remove JSON-RPC support if requested
Context
Avoids potential issues with JSON-RPC. Also keeps the builds faster and smaller (
headless serveronly nojsonrpc
is 2.2M, a full build is 3.4M).Does this change need documentation? What needs to be documented and how?
We should document it as part of the "How to build the server" documentation. But not mentioning it won't directly cause problems.
Status of this Pull Request
My directories and servers have been built with this and run with this for ages.
What is missing until this pull request can be merged?
Should be good to go but @dtinth and @pgScorpio looking over it would probably be good.
Checklist