On 23 April 2013 10:03, Guenter <[email protected]> wrote: > On 17.04.2013 16:03, Daniel Stenberg wrote: > >> On Tue, 16 Apr 2013, Peter Stuge wrote: >> >> I strongly dislike the absolute disconnect between the extremely >>> generic name libssh2_sftp_fsync() and the very opposite name >>> [email protected] - unless libssh2 will in the future use a heuristic >>> to determine which actual extension to use. I don't want that. >>> >> >> I do. >> >> If there would appear another way to fsync in a future, we can introduce >> either a way for libssh2 to figure out by itself what method to use, or >> we provide an API for the application to select method. >> >> At a minimum, I'd like a follow up patch which changes the API name to >>> libssh2_sftp_fsync_openssh_**com() or such.. >>> >> >> Why do think this is necessary? I don't think we do a service to our >> users by exposing the underlying protocol naming in our function names. >> I also suspect that we won't be flooded by lots of other fsync >> variations either... >> >> what about something like that: > > #define LIBSSH2_FSYNC_AUTO 0 > #define LIBSSH2_FSYNC_OPENSSH 1 > > libssh2_sftp_fsync(LIBSSH2_**FSYNC_OPENSSH, ...) > > this way the function name could stay also in the future, users of the > function can select the method to use, and it would be possible to select > an automatic way if it can be implemented ... >
The intentions are good, but we're overengineering here. Is any standard version of this feature realistically going to have an incompatible API? And if, despite sensible predicitons, it is incompatible, is it really the end of the world? We just add a second API call and combine them at the next soname bump. Our API is littered with sub-optimal APIs waiting for the ABI-change green light. Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)
_______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
