On Sat, Sep 12, 2009 at 9:20 AM, Matt W. Benjamin<[email protected]> wrote: > > ----- "Tom Keiser" <[email protected]> wrote: > >> On Thu, Sep 10, 2009 at 7:00 PM, Matt W. Benjamin<[email protected]> >> > [snip] >> Additionally, I really think we should assert our current DV as an IN >> param to allow future implementations to do offset mapping should >> they >> so desire (and offset should become INOUT as a result). > > Ok. I assumed the client might abort the listing if it discovered that dv > had changed, we'll need a way for the server to inform the client it can > continue > a coherent listing, I think. >
Actually, I think I see a good opportunity to reduce the messaging complexity of afs3: drop an XCB notification vector (and probably a "you're caught up now" flag) as an OUT parameter on the RPC. A file server implementing XCB async delivery semantics would then have the _option_ of delivering a subset of queued notifications, thus potentially eliminating a second round trip, and hopefully eliminating the posited desire for aborts. If this works out as well as I suspect it will, we might eventually want to add such an OUT parameter to many of the afsint RPCs. -Tom _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
