GitHub user AlexStocks added a comment to the discussion: [Proposal] Pixiu AI evolution should focus on Dubbo-native differentiation
I think there is also an important **joint strategy** question here: > How should `dubbo-go` and `pixiu` work together in the AI era, instead of > evolving as two disconnected AI narratives? My current view is: - `dubbo-go` should primarily evolve as the **AI-ready service substrate** - `pixiu` should primarily evolve as the **AI capability gateway / control plane** That means the two projects do **not** need to compete on the same layer. They can form a cleaner division of labor: ## Suggested division of labor ### `dubbo-go` Focus on service-side capabilities such as: - AI-friendly service metadata - streaming/session semantics - tool/schema exposure primitives - AI-specific observability on the service/runtime side - governance primitives inside service invocation and service discovery ### `pixiu` Focus on entry/control-plane capabilities such as: - service-to-tool exposure - model/tool/API traffic routing - policy enforcement - tenant/cost/security controls - MCP / gateway / ingress integration - end-to-end observability from user request to downstream service/tool result ## Why this split makes sense If both projects try to become “AI platforms”, they will overlap and dilute each other. If they instead form a layered story, the overall Dubbo ecosystem becomes much clearer: - `dubbo-go` = where enterprise service capability is produced and described - `pixiu` = where enterprise service capability is exposed, routed, secured, and governed for AI/API consumers In other words: - `dubbo-go` answers: **how should services become AI-ready?** - `pixiu` answers: **how should AI systems safely consume those services at scale?** That seems much more defensible than having both projects independently add generic AI features. ## Possible follow-up RFC split If this discussion gains traction, I think it can be split into a few narrower topics: 1. **RFC: Dubbo service metadata model for AI/tool exposure** - target mostly `dubbo-go` 2. **RFC: Pixiu service-to-tool gateway model** - target mostly `pixiu` 3. **RFC: Registry/metadata-driven AI routing across dubbo-go + pixiu** - joint topic 4. **RFC: End-to-end observability for model → tool → downstream service** - joint topic 5. **RFC: Security/governance boundaries between service substrate and gateway control plane** - joint topic I think clarifying this ecosystem-level cooperation model would make the Pixiu AI story much stronger than discussing Pixiu in isolation. GitHub link: https://github.com/apache/dubbo-go-pixiu/discussions/990#discussioncomment-17431513 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
