Hi Petr,

Next, my idea is that the PeersRequestSession class will be the interface for all request sessions (tracker, DHT) and there will be a class that implements this interface, for example PeersRequestSessionTracker (not sure about the name, though) which will internally use TrackerRequestSession, so we won’t need to modify it (and tests). Or do you think that we should derive TrackerRequestSession from the PeersRequestSession directly without using a mediator (PeersRequestSessionTracker)? I don’t mean the design pattern, but just a mediator.

I guess TrackerRequestSession would be the best name for the interface. The different implementations could be called StandardTrackerRequestSession (or CentralizedTrackerRequestSession) and DhtTrackerRequestSession. If we create an adaptor, we would need to test it too. I think best would be to refactor our current StandardTrackerRequestSession implementation towards implementing the new interface (i.e. deriving from the interface class and implementing its functions).

I think that these were the main problems why I decided to create my own wrapper for storing PeersRequestSession pointer. This solution works, but there are actually needed two operator new calls - one for the session itself and one for the wrapper, so there definitely should be a simpler solution.

OK, it’s clearer to me now! What about delegating both the creation and the destruction to the factory object? That’s actually what the std c++ lib is doing with containers - an allocator object is used to allocate and free memory. We won’t need to pass ownership as the factory would be retaining the ownership and will actually delete a session object only when told to do so (factory->closeSession (session)). The factory could thus even assert if we attempt to free the same object twice. What do you think about that?

Best regards,

Peter