As Harold said in another part of this thread, it may well be moot by 2.0.
At 09:49 AM 2/17/99 EST, Greg Hudson wrote:
>Mark Delany <[EMAIL PROTECTED]> wrote:
>> Possibly. What do you propose? The current method guarantees a
>> unique file name first time, every time. Since it's needed for every
>> new mail, you want it to be efficient, right?
>
>Not a very good argument. If some other technique gets a unique
>filename the first time with 1-epsilon probability, then the
>performance difference will be negligible. Having to handle more
>conditions, though undesirable, does not imply significantly reduced
>performance.
I'm not sure I was presenting an argument. I see that a simple, safe and
efficient method has been used to generate a unique file name. You think a
more complex method with failure detection code and "negligible" performance
costs is better because you can move the queue without thinking.
Is should come as no surprise that Dan traded off complexity and occassional
inconvenience for simple, smaller and safe. Especially in code paths that:
a) manage internal, short-lived structures (contrast with Maildir)
b) occur in multiples of concurrency settings
c) create an inconvenience on rare occassions only
d) create an inconvenience that can be mitigated relatively easily with
out-of-band code
It will likewise come as no surprise to long-time watchers if the difference
is a single line of code.
Given that it's not my code I tend to simply explain the choices as I
understand them rather than argue about them.
Regards.
