neo-project
Optional RPC Server plugin dependency
Summary or problem description For cases like https://github.com/neo-project/neo/pull/4161#discussion_r2361427493 we need to provide an ability to disable RPC Server plugin dependency if needed.
For example, dBFT plugin requires StateService for stateroot calculation, but definitely doesn't need RPC Server plugin as a dependency (because RPC should likely be disabled on consensus nodes due to security reasons). However, right now StateService plugin requires RPC Server plugin as a dependency because StateService exposes a couple of RPC methods.
Do you have any solution you want to propose? For now, there are two possible solutions suggested:
- One solution is described in https://github.com/neo-project/neo/pull/4161#discussion_r2361427493: split StateService plugin into two plugins: plugin
Ashould calculate stateroots, pluginBshould expose state-related RPC methods. Then dBFT will be dependent from pluginAonly, it won't introduce RPC Service plugin dependency to dBFT. - Another solution is suggested by @shargon: decouple
RpcMethodattribute implementation from RPC Server plugin and make RPC Server plugin dependency kind of an "optional". So that if RPC Server plugin is installed, then state-related RPC methods of StateService plugin are available, but if RPC Service plugin is not installed, then state-related RPC methods won't be exposed.
Where in the software does this update applies to?
- Plugins
Both solutions are good to me. I think that, in long term, both of them should be implemented, specially option 1.
For now, before 3.9.0 I think that any of them is good.
Both work for me, but 2 is a bit preferable since it's less invasive and easier to manage.
i dont like 2nd solution, easy as it is, but easy and simple should not be our way of working (not to mention its actually not a big deal or big issue or hard issue to fix at all), we should keep consistency, instead of having special case everywhere. simple as it is here, simple as it is there, special case here, special case there, in the end the proejct full of special case and no consistency at all, and when we maintain it, no system design but full of special cases.
Both work for me, but 2 is a bit preferable since it's less invasive and easier to manage.
Like @Jim8y said, This makes more problems for us. RPC extensions should be just that, "extensions", not a requirement.
We have a messy house of code and don't need more when we are trying to fix and maintain this mess. Like I say all the time. One step forward 10 steps back. So, please do option one. We all need to be on the same page here with system designs, not a rando jumping in and doing their own thing. I been trying to get everyone on the same paper since I been working on NEO and all I get is ignored. No more asking, I'm telling you do the 1st one and split State Service. If not, blocked!
Option B is not a bad design, because option A require 3 plugins, B only will increase the state root functionalities if you installed the rpc server, otherwise, only will have the stateroot, simpler it's easier, for devs and users.
Option B is not a bad design, because option A require 3 plugins, B only will increase the state root functionalities if you installed the rpc server, otherwise, only will have the stateroot, simpler it's easier, for devs and users.
Plugins do have a built-in communication protocol for talking to one another. So just put them all in RpcServer.
https://github.com/neo-project/neo/blob/9b9be47357e9065de524005755212ed54c3f6a11/src/Neo/Plugins/Plugin.cs#L241-L246
For me the best option right now is to decouple the RpcMethod attribute into a lightweight abstractions assembly making the RpcServer plugin an optional dependency. In my opinion this approach avoids introducing additional plugins to maintain, keeps StateService as a single module without forcing RPC exposure and minimizes deployment complexity
So you know just because a plugin is using RcpMethod doesn't mean It needs the RcpServer plugin loaded. Just look at the ApplicationLog
Check the implementation of Option 1).
I was carefully with the AI to make this split....aehuahea So, perhaps there is no change in the logic. I also verified accordingly.
As soon as you guys check that PR I will also proceed with some tests and we can follow to @superboyiii.
I still think that Option B is also good to be implemented, as I said.
But both are good to me and I think that if the PR i created worked we can implement both.
But both are good to me and I think that if the PR i created worked we can implement both.
We have to stop allowing this. Having no design makes it very difficult to maintain and add new features. Please follow me and @Jim8y request. We are the developers maintaining this project mostly with @Wi1l-B0t now and we dont like cleaning up everyone else chicken scratch.
The easiest way is to move RpcMethodAttribute to neo library and be done with it.
The easiest way is to move
RpcMethodAttributetoneolibrary and be done with it.
But maybe with other generic game