On 2/11/2011 12:12 PM, Andrew Deason wrote: > On Fri, 11 Feb 2011 11:43:43 -0500 (EST) > "Matt W. Benjamin" <[email protected]> wrote: > >> XCB is structured as a "bulk" interface. Clients receive a sequence >> (actually sequences) of messages, where the messages are in the union >> (ditto for results). I understood the interesting case to be if a >> client receives a sequence of callbacks of intermixed known and known >> type. I would expect clients to ignore unknown messages, but I guess >> the point at issue is whether a sequence containing unexpected union >> records can even be decoded. Can it? > > Currently, no. But with the new union structure, yes. (And you could > even have the application handle the unknown 'blob', if we allow the > application to install a handler for an unknown discriminator, as jhutz > has mentioned) > > But in that situation with XCB, if you get an unknown callback type, > there's not anything you can do with it, so the only thing I can see > happening is that you drop it. And so, you've dropped a callback break, > which means losing information or keeping stale data around in the > cache. I would expect that the fileserver be told that a client doesn't > understand a certain callback type, and so would have to work around it > (probably by sending a Cancelled or something).
The condition of an unknown XCB notification being issued to a cache manager would have to be an error. If XCB is going to support the introduction of new notifications, the cache manager must inform the file server what the supported notification types are ahead of time via the Cache Manager Capabilities. Otherwise, the file server would not be able to send the correct notification form. In the case that such an error condition were to occur, the cache manager would have to treat the receipt of the notification as a generic invalidation just as callback breaks are handled today. Jeffrey Altman
signature.asc
Description: OpenPGP digital signature
