You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@brpc.apache.org by "darion-yaphet (via GitHub)" <gi...@apache.org> on 2026/09/04 06:37:21 UTC
[D] Proposal: clarify codec/serialization module boundaries under src/ [brpc]
GitHub user darion-yaphet created a discussion: Proposal: clarify codec/serialization module boundaries under src/
`src/json2pb` and `src/mcpack2pb` are currently peer directories of `src/brpc`, although they are primarily payload codec/adapter libraries rather than complete RPC protocol implementations.
This layout has historical and reuse-oriented rationale: both are public, reusable components, and `mcpack2pb` also backs `protoc-gen-mcpack`. However, it is not obvious to new contributors why they are outside `src/brpc/policy`.
Would maintainers be open to either:
1. documenting the ownership and boundaries of top-level `src/` modules; or
2. gradually grouping codec-like modules under a clearer namespace/directory, while preserving existing exported include paths?
I understand that a physical move may be source-compatible only with forwarding headers and would also need to account for build rules and `protoc-gen-mcpack`.
This issue is intended to discuss direction before proposing code changes.
GitHub link: https://github.com/apache/brpc/discussions/3519
----
This is an automatically sent email for issues@brpc.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@brpc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@brpc.apache.org
For additional commands, e-mail: issues-help@brpc.apache.org
Re: [D] Proposal: clarify codec/serialization module boundaries under src/ [brpc]
Posted by "darion-yaphet (via GitHub)" <gi...@apache.org>.
GitHub user darion-yaphet closed a discussion: Proposal: clarify codec/serialization module boundaries under src/
`src/json2pb` and `src/mcpack2pb` are currently peer directories of `src/brpc`, although they are primarily payload codec/adapter libraries rather than complete RPC protocol implementations.
This layout has historical and reuse-oriented rationale: both are public, reusable components, and `mcpack2pb` also backs `protoc-gen-mcpack`. However, it is not obvious to new contributors why they are outside `src/brpc/policy`.
Would maintainers be open to either:
1. documenting the ownership and boundaries of top-level `src/` modules; or
2. gradually grouping codec-like modules under a clearer namespace/directory, while preserving existing exported include paths?
I understand that a physical move may be source-compatible only with forwarding headers and would also need to account for build rules and `protoc-gen-mcpack`.
This issue is intended to discuss direction before proposing code changes.
GitHub link: https://github.com/apache/brpc/discussions/3519
----
This is an automatically sent email for issues@brpc.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@brpc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@brpc.apache.org
For additional commands, e-mail: issues-help@brpc.apache.org
Re: [D] Proposal: clarify codec/serialization module boundaries under src/ [brpc]
Posted by "wwbmmm (via GitHub)" <gi...@apache.org>.
GitHub user wwbmmm added a comment to the discussion: Proposal: clarify codec/serialization module boundaries under src/
I think there is no need to change the directory structure.
GitHub link: https://github.com/apache/brpc/discussions/3519#discussioncomment-18301230
----
This is an automatically sent email for issues@brpc.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@brpc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@brpc.apache.org
For additional commands, e-mail: issues-help@brpc.apache.org