[Note that the presence of the hole is not the main point here; the
problem only need occur if the two "contigous" segments do not fit
into memory. -ies]
John May replies:
>I agree, and the argument also works for writes: you might
>want to build up an elaborate filetype partition of the file,
>but only fill up the partition incrementally.
True. The question is whether there is a real need by applications
for this functionality or this is an unlikely corner case. I don't
believe it would be required for our applications, but I don't know
about other sites.
>In general, I think we need to be very conservative about
>making changes at this point. Most of the functionality
>in the chapter has been implemented by one or more of us,
>and we've learned a lot about what's feasible and what isn't
>through these implementations. Many things that looked
>straightforward turned out to have subtle problems. Rash
>changes made now will be hard to fix. I'm already nervous
>about filters, even though they look like a good idea.
This is a key point. My original suggestion was motivated by the
belief that we were carrying along possibly unnecessary complexity,
and that we might be able to trim it by an additional constraint
(whole filetype accesses). Rajeev and Bill N. have identified and
specified important details. Given those, I still don't think this is
a big change - the amount of text changed is small, as is the loss in
functionality - but I don't propose that we rush into this without
satisfying ourselves that this is really true.
If this really is a major change, then we don't want to do it.
-Ian
-- Ian E. Stockdale MRJ Technology Solutions, NASA Ames Research Center ies@nas.nasa.gov (use ies@acm.org for non-work email)