I see now. This important detail was not covered in the proposal and hence I was under impression that you are not modifying the core fabric code. Given, the first point above, this would cause more changes in the peer core.
I see. We'll keep looking into a solution for this kind of situation and update of the proposal as well.
As I mentioned previously, it can still be event driven (event from archiver repo). My main point was point-to-point communication vs gossip.
I understood. I agree that it might be better pub/sub messaging type rather than broadcasting.
All I wanted to say here is that, it would be good if someone wants one of the peers file to act as a repo as well…. in other words, it still has all what a repo offers and code will be outside core peer code anyways. But this is less important point as compared to others, I guess.
Yes, ultimately we'd like to introduce that kind of new peer role called 'repo' that offers the same functionality with the current repository reside to the existing peer node functionality.