Hi, As I mentioned to Derrick, you should request a server and perhaps a client capability flag, perhaps for precisely the experimental protocol which now exists. Past that, perhaps it would be helpful to redirect this discussion to afs3-stds, if you're interested in getting a short list of real deployment issues the wider community would be concerned about (e.g., security implications, and satisfactory means of assuring no one is accidentally burned).
Matt ----- "Andrew Deason" <[email protected]> wrote: > On Mon, 26 Mar 2012 16:15:28 -0400 > Derrick Brashear <[email protected]> wrote: > > > > I am also currently not releasing the code publicly, because the > > > protocol used in it is a nonstandard extension (although using > reserved > > > RPC code points), and I don't want someone running this in a > public > > > cell. But am I just being overly cautious and silly about that? I > have > > > no problem with code review (though it seems a bit early for that) > or > > > people experimenting with it or anything, but I just imagine what > > > happens if Joe Q Admin sees "here's some code to make afs go > faster"... > > > > the sort of people to whom it would be useful would be only the > ones > > who control their whole environment anyway; > > Well sorta, but... while you need to control the server and client > for > it to make a difference, if you install it on client A and fileserver > B, > if fileserver B is _also_ open to the outside world (or client A can > contact the outside world), that seems like a problem. > > > i'd expect packagers to steer clear of it and thus unless someone > was > > building their own stuff end to end it wouldn't matter anyway. > > Well... some people do do that :) Less common on Linux, though, I > suppose, though pulling patches into existing packaging frameworks > isn't > hard. > > I also meant to mention that this is all Linux-only at the moment. > The > fileserver bits are trivial to port, but I assume the client bits are > more work (at least, in order to do zero-copy stuff...). > > -- > Andrew Deason > [email protected] > > _______________________________________________ > OpenAFS-devel mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-devel -- 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 _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
