Re: [Libtirpc-devel] Proposed enhancement to libtiroc

[Yair L. <yai...@gm...>]

The reason I'm proposing this solution is to get feedback from other
members - I would not classify it as "putting the cart before the horse".

If the team/community prefer that that TIRPC should stay "frozen" - with
the exact same set of features/API that were approved in RFC 4506/1832
(2006, 1995), and that the path for approval is via RFCs - that's is clear
feedback for my proposal.

Thanks for you input/feedback,

Yair

On Mon, Jan 26, 2026 at 5:07 PM Chuck Lever <chu...@or...> wrote:

> 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
>