search

anacrolix / torrent

Full-featured BitTorrent client package and utilities
Mozilla Public License 2.0
5.58k stars 630 forks source link

Expose torrent Peer status updates #987

Open marcovidonis opened 1 month ago

marcovidonis commented 1 month ago

Provide updates on peer status which include peer ID, ok status, and an error message. This can be useful for the client to be notified of errors when running a connection after handshake.

Updates are sent via channels to Observers, which are set up by the client in config.

anacrolix commented 1 month ago

I'm not sure about this one. I don't think channels are a good way to handle events unless there's explicit concurrency cooperation required. In the case here where we are updating status information, there's no cooperation, we're just telling users of events. I think I started setting up https://pkg.go.dev/github.com/anacrolix/torrent#Callbacks as a way to handle various events that occur in the client. In particular if you wanted to have a subset of this exposed to various subpackages, like trackers, webtorrent etc. you would create a callback struct for each of those and embed it in the larger one in the client. Having synchronous events lets the user act on or even alter behaviour as appropriate. As for the various status objects, what do you think of just exposing those internal types where possible instead? I believe I started this process for Peer, PeerConn, Torrent and a few others, and their public API is mixed but could be extended.

In general I think introducing observers, and meta types to track their state creates new API contracts that are particularly hard to navigate around. I could be completely wrong but it just doesn't feel right. There have been plenty of bad API choices in anacrolix/torrent to date that I'm stuck with.

marcovidonis commented 1 month ago

Thanks for getting back to me on this. I generally like channels as I feel I can give real-time updates as things happen, but I see your point and I'll look into changing this into callbacks (when I get some time). As for exposing internal types, I think I picked up the pattern of writing getter functions early on, and only recently learned that it's actually not a recommended pattern! So yes, I totally agree with just exposing those types.