Proposal: make all transports open structs

[findleyr]

It may be late for this change, but I think we can simplify the transport API, and I'd like to strongly consider doing so.

Unlike other SDKs, we made the decision to have a Connect method on the Transport interface, rather than the stateful Start. This means that all of our transports are inherently stateless: when Connect is called, they create a stateful connection.

But that means there's really no reason for having constructors with options. Our transports could just be open structs. For example:

type CommandTransport struct {
  Command *exec.Cmd
}

type StreamableClientTransport struct {
  URL string
  HTTPClient *http.Client
  ReconnectOptions *StreamableReconnectOptions
}

etc. etc.

By my count, this could eliminate 10 symbols.

• NewCommandTransport
• NewLoggingTransport
• NewSSEServerTransport
• NewSSEClientTransport
• SSEClientTransportOptions
• NewStreamableServerTransport
• StreamableServerTransportOptions
• NewStreamableClientTransport
• StreamableClientTransportOptions
• NewStdioTransport

Furthermore, we've been inconsistent about which transports get options, and I can foresee us wanting to add options to all of them. Making this change now allows us to be future-proof, without having to further pollute the namespace.

v0.3.0 is necessarily going to contain other breaking changes. I think we should consider these as well. If we want to ease the breakage, we can deprecate the NewXXX constructors and remove them in a later release (they are not incompatible with this change).

CC @jba @samthanawalla

[jba]

Sounds good to me. This seems like a relatively minor change.

I'd remove the constructors in v0.3.0

[findleyr]

Since this is done, and no objection to the proposal, I'm going to mark it as accepted and fixed.
I'll open a separate issue for removing the transport constructors prior to the release.