Hi Peter,

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).

Ok, sounds good to me - I’ll first rename the current TrackerRequestSession to StandardTrackerRequestSession and after the new iterface is done I’ll refactor the StandardTrackerRequestSession to use it.

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?

Great idea! I’ll surely do it this way. I’m now thinking (maybe you meant it that way, too) that the (real) factory itself could internally store a list of created sessions and close all of them (that are not closed) in the dtor - what do you think?

Regards,

Petr