On 23 April 2013 10:03, Guenter <lists_at_gknw.net> 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
>>> fsync_at_openssh.com - 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
Received on 2013-04-23