define Resolver type

[daniellacosse]

Am I doing this right????

[jyyi1]

Thanks @daniellacosse , it would be helpful if you can illustrate more about the future use cases of this interface? And welcome to the Go world!

[fortuna]

Thanks for starting this. I believe the best way to go about it is to discuss in person with some whiteboarding.
Can you set up some time with me and @jyyi1 for tomorrow to discuss and brainstorm?

[daniellacosse]

Thanks for starting this. I believe the best way to go about it is to discuss in person with some whiteboarding. Can you set up some time with me and @jyyi1 for tomorrow to discuss and brainstorm?

I've set up time next week!

[jyyi1]

A function is unmodifiable. Think about the following scenario:

dohResolver := NewDoHResolver(...)
dialer := NewDialerWithResolver(dohResolver)
// ... initially
dohResolver.SetTimeout(xxx)
// ... after some time
dohResolver.SetTimeout(yyy)

Unless we decide that all our Resolver implementations are immutable, I would prefer to define it as an interface:

type Resolver interface {
  LookupIP func(string)([]string, error)
}

[daniellacosse]

Why would they need to be modifiable? I guess I don't see a reason it shouldn't be immutable

[jyyi1]

For example Intra allows to you change the DoH server on the fly (without reconnecting).

[daniellacosse]

And switching out the one resolver function with another wouldn't work in that case?

[jyyi1]

Sure it does. But it also means we will create a new interface in the app that wraps around this func.

[daniellacosse]

Do we? Why can't it be a property on an existing struct?

[jyyi1]

Well yes, defining a struct that wraps around the function, which is OK for a single app.

My concern is whether a "stateful" Resolver is common across all apps, and how it interacts with StreamDialer and PacketProxy.

For example, some implementation might maintain a connection to a remote server, then we need to have Close() function in the Resolver to prevent resource leak.

We can discuss them in the brainstorm meeting, it all depends on the use cases we would like to cover. We might need to consider more stuffs than the LocalResolver or shadowsocks.StreamDialer.

Another thing I can think of is the two Resolve methods, one with context.Context and one without (similar to Go Dialer's Dial and DialContext)? We can discuss whether we should support it too.