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