Andrew Deason wrote:
On Tue, 14 Dec 2010 10:47:22 -0500
Derrick Brashear <[email protected]> wrote:
b) Do something with the version string in the meantime
i'm not wild about this.
I kinda would want to explore this more. This doesn't seem worse than
the GetStats approach, and makes a certain amount of additional sense.
It doesn't catch all cases, but it catches the common case where someone
builds the code without changing anything or doing anything special.
It also does not affect other potential implementations and avoids
implicit relationships between otherwise unrelated parts of the
protocol. At least, in theory; it obviously ties the RX version response
to GUACB behavior but I think that makes it very very obvious that it's
a minor implementation-specific quirk.
I'm unsure of the reliability of rx version packets, though. And the
existing libraries I think make this more annoying and involved than a
regular RXAFS call, which makes this much less appealing...
This does catch the most common case of a fileserver running a vanilla
openafs release. I have seen people append patch level info to the
version string, but I don't think it is very common to change the
major.minor version numbers. This approach maybe the best of a bad
set of choices of we do not want to release a client that uses a
known buggy rpc for fileservers which were and may still be in production.
Derrick said:
> An RPC with a version vector or something more reliable than a text
> string has already been discussed and is presumably going to be in the offing.
So, if I understand, then the version string check (or get-stats rpc check) is
meant to be a stop-gap?
Mike --
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
