Hello Ronnie,
please find my 2 cents below ...
On Tue, 27 Jun 2023, ronnie sahlberg wrote:
As the developer of libnfs I am asking for advice here.
In order to implement "zero-copy" read support I had to break he
API for read(), which realistically breaks the API for every single
application. So I took the opportunity to fix other warts in the
interface as well (like rpc_* functions should return a handle that
could be cancelled)
This is a 100% API breaking change. So advice please on going forward.
What does debian packaging and maintainer folks think?
I am personally leaning towards leaving the current libnfs and API in
a frozen maintenance state and publish the massive API changes in a
libnfsv2 project?
From a developer perspective (my view), this seems to be a quite
reasonable way to go. So it would be simply clear for an application
whether to link via '-lnfs' (still using the current API) or to link
via '-lnfs2' (using the new API from the future) similar to FUSE2/3
for instance. And then also the path /usr/include/nfsc would need to
be changed to /usr/include/nfsc2 or anything alike, and libnfs.pc
would need to be renamed to libnfs2.pc to allow co-installability of
the different *-dev packages.
What should I do and how should I do it? The API changes are useful
for going forward but they will break all backward compatibility.
Personally, I would not start a new project if it would be possible to
implement a compatibility layer on top of the new API, maybe labelling
the older symbols as being deprecated. But if you need to keep the
same function names for the new API as well, then starting a new
project seems to be the best possible solution.
For now, this API breakage and zero-copy read is contained in the
special libnfs-next-gen branch.
But this has not yet been part of version 5.0.2, right?
Best regards,
Thomas Uhle
