During a relocation an intermediary RequestDone events is fired. Is this really needed, and for what propose?

Relocation is considered as a another automatic request. You may cancel it on the fly or simply disable the feature with FollowRelocation property.

Yes, but if I want to follow it, I think it would be better if this intermediary (for the result of the request) RequestDone could be clearly identified in this event. If I need to process the received response, I need to know when I'm dealing effectively with the final one.

If yes, then I think it should be fired with the correct response status code, not zero as now, so it can be clearly detected as not the final request done even. Also, an "httpRelocating" THttpState could be handy.

Changing the behaviour is likely to break a lot of existing code.

There are code relying in this no meaning StatusCode=0?!
This very limiting of code improvements "no breaking code" rule could be improved with a "supported version", as used by many API's today. At compile time with a "maximum version" compile switch, at component creation with a maximum code version property, etc.. Default to the legacy switch/property version, and new/upgraded code can set it to the last code behavior version.

To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

Reply via email to