[AFS3-std] updated extended callback draft

[Chaskiel M Grundman]

> What I'm really trying to say is:  synchronous delivery of invalidates
> cannot assert consistency for the system, because it presumes
> consistency before the callback event--and due to (at least)
> write-on-close, the presumption is in interesting cases, commonly false.

What if an application tries to prevent the client from caching disjoint
sets of dirty data, by using locking? your change could cause such an
application to see its assumptions violated:

Client 1            Client 2
open()
flock(LOCK_EX)
read()
close()

                    open()
                    flock(LOCK_EX)
	            read()
                    write()
                    close()
         <-- callback break happens(now)
open()
flock(LOCK_EX)
read()
          <-- callback break happens (future)
read()


Alternatively, what about applications that use both the filesystem and
their own network transport? application on node X updates a file, closes
it and makes an rpc to node Y, which sees the old contents of the file, or
no file at all!