update the peerstore, change the peerstore option

[marten-seemann]

No description provided.

[marten-seemann]

This is annoying. NewHost will panic if the EventBus is not set.
Should we make the event.Bus a function parameter of NewHost?

[vyzo]

that sounds like the right thing to do

[vyzo]

I am beginning to suspect we should have put the pstore manager in the host ans avoided this mess... oh well.

[marten-seemann]

I am beginning to suspect we should have put the pstore manager in the host ans avoided this mess... oh well.

I had the same thought. But logically, it does belong to the peerstore and not to the host. I suppose the long-term answer here is dependency injection, but I don't want to cross that bridge now.

[burdiyan]

Agree very much with @vyzo on: #1256 (review).

FWIW, quoting myself from libp2p/go-libp2p-peerstore#186 (comment):

I'd argue the opposite, actually.

IMHO, logically the cleanup work does belong more to the Host than to the Peerstore. Peerstore just deals with storage and should not be responsible for cleaning things up. It does provide the means to remove records but it could be free from the responsibility of doing that. Actually this is how it is already, since the logic is actually implemented in a separate PeerstoreManager type, and I do think that it's a good design decision.

But in terms of who's responsible for creating and starting the PeerstoreManager I strongly believe that architecturally it's a lot cleaner if Host is responsible for that, or even the caller who creates the Host. There're already lots of things that are encapsulated inside the Host interface, and this could be one more. It also helps with understanding of things, when you know that all the side-effects and background-related routines are initiated in one place. It also makes implementing Peerstore interface easier, because you don't have to think about creating and starting the PeerstoreManager in every Peerstore implementation, which is a thing that could be easy to forget.

Of course all of this is subjective, and both approaches will do the job. I just wanted to bring up some thoughts and ideas as a person who's not involved with Protocol Labs, had been working with Libp2p and IPFS for couple years now, using the most lower-level components available and assembling them manually. And I honestly find lots of confusing things in terms of responsibilities between all the different components.