On Fri, 11 Feb 2011 14:34:56 -0500 Jeffrey Hutzelman <[email protected]> wrote:
> I think extensible unions are a good fit for XCB, because of the bulk > delivery mechanism. But yes, you'd need a way for the client to > indicate to the fileserver which of the XCB entries it understood, and > perhaps to return a per-entry error code, in the same way that > RXAFS_BulkStatus does. I had thought that what callback types the client understands would be handled at a higher layer, like capability bits. And if you accidentally send the client a type they don't understand, you've got a serious divergence of what you think the client is, and should renegotiate the client capabilities (or even the entire callback state). But that's just one way. I could see the XCB messages using an extensible union, but relying on that to have the client tell you what callback types it doesn't understand is problematic. If you send the client a callback of type X, and the client says it doesn't understand type X, do you just not send callback type X... forever? If the client gets upgraded to understand callback type X, you don't have a way to know when to start sending them again, unless you rely on capability negotiation. In which case, well, the caps should tell you what the client understands on its own. On the other hand... I suppose if you use an extensible union, you may get more information about which specific callback caused the error, which could be helpful for debugging and such. So, maybe there's a win there. -- Andrew Deason [email protected] _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
