[AFS3-std] Callback Extended Information Draft 4

[Matt Benjamin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Ie, something different from:

Create AFSExtendedCallbackV2, which aggregates an AFSExtendedCallbackV1,
and then adds new members.  Create ExtendedCallbackV2 taking
AFSExtendedCallbackV2 as argument.

Matt Benjamin wrote:
| I worried about this.  Can you suggest an elegant alternative?
|
| Matt
|
| Jeffrey Hutzelman wrote:
| | --On Wednesday, May 14, 2008 02:38:20 PM -0400 Matt Benjamin
| | <matt@linuxbox.com> wrote:
| |
| |> -----BEGIN PGP SIGNED MESSAGE-----
| |> Hash: SHA256
| |>
| |> Actually, Derrick has convinced me we should be able to rather
| |> seamlessly add new types to the union.  Certainly handwritten routines
| |> calling XDR_decode should have no difficulty dealing with an unknown
| |> event type--which we should define as equivalent to a traditional
| |> callback, I would think?
| |
| | I'm not sure what "handwritten routines" you're talking about.  RPC
| | arguments are completely decoded before the handler is called.  If the
| | union discriminator is not a known value and there is no default branch,
| | then the framework will abort the call with RXGEN_SS_UNMARSHALL without
| | ever calling the handler.  Adding a default branch doesn't help you,
| | because it would have to exactly match what is sent in that case, which
| | you can't predict in advance.
| |
| | So, an unknown event type will be handled by returning
| | RXGEN_SS_UNMARSHALL, and the server should handle this case gracefully.
| | Ideally, the server should not send notification types for which the
| | client has not indicated support.
| |
| | -- Jeff
| |
| | _______________________________________________
| | AFS3-standardization mailing list
| | AFS3-standardization@openafs.org
| |
|
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization

|
|
| |
|
|
|
|

- --

Matt Benjamin

The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIK1tqJiSUUSaRdSURCPqbAKCVcrbqpdNWxcBoD7sKR4quMAKHRgCfWRlJ
zyiOFYtCHM3IeL0okv3VSRg=
=/SGq
-----END PGP SIGNATURE-----