Re: [Libtirpc-devel] Proposed enhancement to libtiroc

[Chuck L. <chu...@or...>]

On 1/26/26 3:14 AM, Yair Lenga wrote:
> Hi.
> 
> I agree with you about the "long chain to pull". There is no practical
> option of changing the RFC, or to convince ALL the implementations out
> there to accept new functions.
> 
> On the flip side, I believe that there is value in enhancing the library
> (in a way that does not break backward compatibility). The benefit I see
> (for this improvement, and potentially other improvements) is for
> actively developed applications, which are based on actively
> developed distributions (Ubunton, RedHat, ...).

Linux is not the only implementation of TI-RPC. Adding a non-standard
API to the Linux TI-RPC library will make any application that uses it
non-portable, unless the other TI-RPC implementations also adopt it.

The whole point of the structure of the libtirpc API is that it provides
a /portable/ RPC API. Clearly we can provide any API we like on Linux.
The value of libtirpc is that it aligns well with the same APIs on
other platforms.

I'd like to see demonstration that the benefit of providing this helper
API outweighs the costs to developers for having to deal with a feature
that is available only on one platform. I bet libtirpc might already
have one or two Linux-only features. It would be helpful to contrast and
compare so that we can get a sense of what value is added by them and
that we then remain consistent with already-established patterns.


> So I can see two options - I can make another fork of TIRPC - enhance
> it, and hope that users will find the change, evaluate it and will take
> the risk of jumping from a vendor supported version into unknown fork
> (VERY UNLIKELY), or try to work with the main TIRPC repos which are used
> by most platform - and get the change accepted - which is what I'm
> trying to do.
> 
> You are correct that making it part of RPCGEN (as opposed to using
> #define macros) will make it easier to adapt this function. I believe
> Thorsten Kukuk, who took over maintaining RPCGEN (when glibc removed the
> RPCGEN/SUNRPC) is on this mailing list. I am very HOPEFUL that there can
> be a similar path to also evolve RPCGEN - but this is not required for
> this feature to be usable.
> 
> Emphasizing:
> * No plan to get TIRPC/RPCGEN to "compete" with protobuf, AVRO or any of
> the other modern implementations. Goal is to extend the life of existing
> applications that use RPCGEN/SUNRPC - to benefit from significant
> performance improvements with minimal effort, without having to go
> through massive rewriting.
> * I've already implemented the changes on my own systems (with forked
> RPCGEN). My motivation is make it easy for other application to leverage
> those benefits with minimal effort.

So adding a new API to a library because only you feel it might be
useful is putting the cart before the horse. Let's see some demand for
it first. Otherwise the risk for us is that we have added something that
will become nothing more than community technical debt.


-- 
Chuck Lever