Hi Peter,

I moved this general problem description from GenericSession to Session’s docs. I thought that the abstract problem description belongs belongs with the solution abstraction. When reading the docs of GenericSession one would read about the details of the implementation and if one wants to read about the general picture, one should look at the interface which the class is implementing. What do you think?

Yes, I definitely agree!

// \todo NullObject for SessionStatus to avoid if (status != 0).

Good idea.

DataSerializer
\todo What about returning a Null Data object if nothing could be read? Maybe the current approach is better though because it is more explicit?

I’d stick to the current approach in this case and if we find out that there are too much if’s when handling Data (and that a Null data object could become handy), we can refactore it. It’s now consistent to the DataSerializer::write() approach, too.

\todo What should be better do:
- say very broadly “read and write Data”
- or say more specificall “read and write Data from and to Transport”
If we chose the latter then maybe we should express that by passing the Transport object by reference to read() and write(). Actually DataSerializer is used (currently only) in GenericSession, which relies on the fact that DataSerializer does read and write to Transport. The methods read() and write() are called in response to Transport notificatons.

If the DataSerializer wouldn’t be “used” (maybe exploited is a better word) for writing data into something different than a transport (e.g. directly to a file), I’d write there explicitly that it writes/reads data to/from a transport. The idea of passing a Transport object by reference to read() and write() functions makes sense for me and I think it would become more clearer!

\todo Again as in DataSerializer, should we make the binding with Transport explicit? Maybe changing open() to open (Transport *). The session would then attach itself to Transport’s TransportStatus?

Considering the previous todo, I’d do that. But now I’m thinking that the current approach is good in the way that one can’t close a Transport that’s different from the one that the Session was using… But we don’t have to add a Transport * parameter to the close() function, so ignore the previous sentence :).

\todo Switch to passing Transport * instead of Transport & (as a convention for differenciating between Value Objects and Reference Objects). That would require updating a few classes.

If we choose this convention, then definitely yes.

\todo Should each Interface interface has a method setStatus (InterfaceStatus *), which would allow us to change the listener at runtime? For example, a HandshakingSession could register as a TransportStatus first and once handshaking is finished, a PacketSession would register itself using setStatus (this).

I was first wondering why there are the setStatus() functions :). Could you please expand the example a little bit? I don’t get why we would need to change the status notifier in the example if there are two separate sessions (handshaking and packet). Maybe if there is a session that can “do more things” or can change it’s behavior dynamically than it would be useful.

\todo Prefix the interface name (e.g. session) to all notifications - that would help us avoid name clashesh in case one class implements two status interfaces that happen to have functions with the same signatures.

Regarding your example in the previous post (Transport could derive from both Buffer and from Connection) I’d agree with that, so there wouldn’t be collisions. And I also agree that a multiple inheritance in interfaces could be useful.

I’ve left some todos uncommented because I don’t feel I have anything to say to them for now. New docs are ok and clear to me. It’s great that I had an opportunity to learn something new about sessions today and that I could use some ideas in the TrackerRequestSession - I’m going to work on this one as my next step.

Good night,

Petr