Re: TrackerRequestSession - questions/ideas

Hi Petr,

The tests look good!

You could probably move the “// Response body handling” part inside the first if, then you don’t need the return in the else and the flow will be clearer.

Try elaborating on the closing scenarios: http session closed while waiting for the responseBody; after close()-ing the http session, waiting for httpSessionClosed() befor signaling trackerRequestSessionClosed(); etc.

I think you might add abort() too - if will send the closed() notification immediately.

You could also have a look at RFC 2616 Section 10.4 Client Error 4xx about the different HTTP 400 error codes. We should think what we should do in case of an HTTP server error response - maybe think of a way to report HTTP errors and tracker errors (ones reported in the bencoded dictionary) in an uniform way to the user code. Maybe plain strings (”HTTP server responded: 404 Not Found”, or “Tracker responded: Unknown info_hash”) and a single status notification, or plain strings with two status notifications (e.g. trackerRequestFailedOnHttpError (”404 NotFound”) and trackerRequestFaildOnTrackerError (”Unknown info_hash”)?

Regards,

Peter

Would you like to post a relpy?


This post is a reply to:
Re: TrackerRequestSession - questions/ideas
Hi Peter, thanks for comments! Http::Header and its derived classes should implement a Value Object, so we should provide operator==(). The operator()== implementation compating the raw representation of the Header objects (more...)

Follow-ups:
Re: TrackerRequestSession - questions/ideas
Hi Peter, You could also have a look at RFC 2616 Section 10.4 Client Error 4xx about the different HTTP 400 error codes. We should think what we should do in (more...)
Re: TrackerRequestSession - questions/ideas
Hi Peter, You could probably move the “// Response body handling” part inside the first if, then you don’t need the return in the else and the flow will be clearer. Yes, (more...)