Re: [Tools-arch] Recommendation 6: Architectural model for clients

[Martin Thomson <[e-mail]>]

On Fri, Apr 9, 2021, at 15:14, Mark Nottingham wrote:
> I think I agree with Robert here, but I'd like to understand what's 
> driving towards centralisation. If there's some 'source of truth' 
> necessary, an API might make sense; however, my current mental model is 
> that the tools should operate on well-documented formats, which can 
> live in a variety of places (e.g., data tracker, my local disk, GitHub, 
> a server somewhere).

I like that model, but I want to ensure that we all understand what that entails.  Right now, we have a bunch of tools that are generally deployed as command-line utilities.  In general, these take a file (or files) and a bunch of options.  They produce a status code and output that might be directed to a file.

We ship these in a variety of ways.  I get xml2rfc using pip.  I get kramdown-rfc2629 using gem.  I get idnits and rfcdiff by downloading a tarball from tools.ietf.org.  Other people don't bother with the getting part, they just use a web page.  Others cases (rfcdiff for instance) effectively use scripted remote access to underlying web resources.

That is largely good.  We provide flexibility, but the overall complexity is low.  A user that climbs the complexity curve from web page to remote access to command-line has a few minor hurdles to clear that we might help them with by documenting each tool better, but the overall shape of the system seems right to me.

We manage these tools in different ways too.  Most are individually maintained, and so are subject to whatever the individual maintainer prefers (GitHub more often than not).

As far as centralization goes, what I would like to see is a deliberate decision to sponsor tools that will get additional resources.  What that might mean is greater consistency of support (more updates, x.ietf.org hosting, help with fixing bugs), greater consistency of interface (at different levels), greater functionality (by paying for features to be added), or other things we might collectively value.

Sponsorship might come with some modest conditions.  For instance, if we believe that a particular tool is valuable enough to sponsor we might decide that sponsorship is conditional on: it being written in a language better suited to maintenance, or hosted somewhere more conducive to community input, or distributed using a more reliable platform, or that it gets a better test harness that can be automated (note: I don't know if any of these things are concretely problems; that would be something that would need to be assessed for each tool).