> Moving to implementation details, our first thought was to call this > new function "vos dump -estimate" and we've gone ahead and coded up > a working implementation of this, but in hindsight we think perhaps > this is not the best choice and we should make it "vos estimate" > instead. The "who really cares which way you do it?" answer turns out > to be hiding in the coding details. > > Adding a -estimate flag to vos dump required adding an extra parameter > to the existing vos dump RPC call, which breaks backward compatibility > with existing vlservers and vos command suites. This seems like a bad > thing to do when it can be easily avoided. > > Adding a new vos command "vos estimate" leaves vos dump as is so it > remains backward compatible. Instead it requires adding a new RPC > opcode. We are currently inclined to proceed in this direction, but > would like to pause for a moment and submit some questions and gather > feedback before going any further with this.
If you're modifying vos to add a new command, couldn't you just code up the change so that 'vos dump -estimate' sends the new RPC rather than a modified version of the existing dump RPC call? Or as a different possible interface, how about 'vos examine -dumpsize' to get it to show the size you're looking for rather than the one it shows currently. _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
