marsevilspirit opened a new pull request, #2892:
URL: https://github.com/apache/dubbo-go/pull/2892
I want to do this because the current unreasonable architecture of the
protocol has affected my development.
Let me give an example.
If we want to add proprietary parameters to the Triple protocol, such as
EmtryOption, the ideal API would be as follows:
```go
package main
import (
"context"
greet "demo/proto"
_ "dubbo.apache.org/dubbo-go/v3/imports"
"dubbo.apache.org/dubbo-go/v3/protocol"
"dubbo.apache.org/dubbo-go/v3/protocol/triple"
"dubbo.apache.org/dubbo-go/v3/server"
)
type GreetTripleServer struct {
}
func (srv *GreetTripleServer) Greet(ctx context.Context, req
*greet.GreetRequest) (*greet.GreetResponse, error) {
resp := &greet.GreetResponse{Greeting: req.Name}
return resp, nil
}
func main() {
srv, err := server.NewServer(
server.WithServerProtocol(
protocol.WithPort(20000),
protocol.WithTriple(
triple.WithEmtryOption(),
),
),
)
if err != nil {
panic(err)
}
if err := greet.RegisterGreetServiceHandler(srv,
&GreetTripleServer{}); err != nil {
panic(err)
}
if err := srv.Serve(); err != nil {
panic(err)
}
}
```
Of course, one might want to write it like this:
```go
srv, err := server.NewServer(
server.WithServerProtocol(
protocol.WithPort(20000),
protocol.WithTriple(),
protocol.WithTripleServerEmtryOption(),
),
)
```
This can indeed solve the problem without restructuring the protocol, but it
puts a lot of pressure on the protocol. As the options continue to increase,
the protocolConfig struct will become bloated, and all parameters must be
transmitted through the URL, making management quite cumbersome.
So the ideal API looks like this:
```go
srv, err := server.NewServer(
server.WithServerProtocol(
protocol.WithPort(20000),
protocol.WithTriple(
triple.WithEmtryOption(),
),
),
)
```
Triple's proprietary options will not be in the protocolConfig struct but in
the Triple struct, and the same goes for other protocols, greatly increasing
manageability and reducing the complexity of the config.
Ok, so I started to implement the triple options and pass parameters through
the protocol options. However, when I finished the triple options and was about
to put them into the protocol options, Oops, a circular dependency appeared.
I imported it like this:
```go
package protocol
// The current package is dubbo.apache.org/dubbo-go/v3/protocol
import "dubbo.apache.org/dubbo-go/v3/protocol/triple"
```
Everyone can see how this could lead to an import cycle; it seems quite
reasonable. That's right, the problem is not with me, but with the architecture
of the protocol. The interface of the protocol is built on top of all
protocols, causing all protocols to reference the upper layer package. If I let
the upper layer protocol package reference other protocols, it will create a
circular dependency.
We should solve this problem; the code here has not been touched for 6
years, and it is time for a change.
The solution is to change the position of the interface and baseProtocol in
the architecture, conceptually placing them at the bottom layer, and then
allowing other protocols to reference the lowest layer package.
before refactor:
after refactor:
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@dubbo.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscr...@dubbo.apache.org
For additional commands, e-mail: notifications-h...@dubbo.apache.org
