Eric Larkin wrote:
Obviously we'll work around the problem in the future, but it is
disheartening to find a fairly subtle bug, report it with a reproducible
test case, and be challenged so aggressively on the whether it was a poor
decision to use "ns_returnfile" a file.

I've remained silent on this issue because I didn't want to be accused of "stifling the community," etc., but I have to agree: the majority of responses is disappointing. As I see it:

1) This is a defect. Jim has explained that the caching strategy implemented for fastpath solved a specific problem and may fail in situations not meant to be solved by the strategy.

2) Attacking John, and by extension, Eric and his company's product, is poor form, regardless of whether this is or isn't a defect.

3) While I agree that serving short-lived data from a disk file in response to a dynamic request is a poor strategy, it _should work_ correctly--which is why I agree that this is clearly a defect. If it works correctly at a cost to performance is a decision that Eric's team must evaluate and accept or find alternatives to. The trade-off should not include "program execution correctness" as a consequence.

4) I see the simplest (best?) solution here being a configurable parameter that controls fastpath's cache key generation. As Jim points out, one can quickly test whether this would solve the problem at hand by temporarily #define'ing _WIN32 in the appropriate place. If this proves successful, we change it from using #ifdef's to regular if() statements and define a new configuration parameter. End of discussion.

Dossy Shiobara              | [EMAIL PROTECTED] |
Panoptic Computer Network   |
  "He realized the fastest way to change is to laugh at your own
    folly -- then you can let go and quickly move on." (p. 70)

AOLserver -

To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> 
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
field of your email blank.

Reply via email to