All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phil Sutter <phil@nwl.cc>
To: Thomas Haller <thaller@redhat.com>
Cc: NetFilter <netfilter-devel@vger.kernel.org>,
	Pablo Neira Ayuso <pablo@netfilter.org>
Subject: Re: [nft v2 PATCH 3/3] py: add input_{set,get}_flags() API to helpers
Date: Fri, 14 Jul 2023 11:59:41 +0200	[thread overview]
Message-ID: <ZLEcjSPnc3PoN57E@orbyte.nwl.cc> (raw)
In-Reply-To: <20230714084943.1080757-3-thaller@redhat.com>

Hi Thomas,

On Fri, Jul 14, 2023 at 10:48:53AM +0200, Thomas Haller wrote:
> Note that the corresponding API for output flags does not expose the
> plain numeric flags. Instead, it exposes the underlying, flag-based C
> API more directly.
> 
> Reasons:
> 
> - a flags property has the benefits that adding new flags is very light
>   weight. Otherwise, every addition of a flag requires new API. That new
>   API increases the documentation and what the user needs to understand.
>   With a flag API, we just need new documentation what the new flag is.
>   It's already clear how to use it.
> 
> - opinionated, also the usage of "many getter/setter API" is not have
>   better usability. Its convenient when we can do similar things (setting
>   a boolean flag) depending on an argument of a function, instead of
>   having different functions.
> 
>   Compare
> 
>      ctx.set_reversedns_output(True)
>      ctx.set_handle_output(True)
> 
>   with
> 
>      ctx.ouput_set_flags(NFT_CTX_OUTPUT_REVERSEDNS | NFT_CTX_OUTPUT_HANDLE)
> 
>   Note that the vast majority of users of this API will just create one
>   nft_ctx instance and set the flags once. Each user application
>   probably has only one place where they call the setter once. So
>   while I think flags have better usability, it doesn't matter much
>   either way.
> 
> - if individual properties are preferable over flags, then the C API
>   should also do that. In other words, the Python API should be similar
>   to the underlying C API.
> 
> - I don't understand how to do this best. Is Nftables.output_flags
>   public API? It appears to be, as it has no underscore. Why does this
>   additional mapping from function (get_reversedns_output()) to name
>   ("reversedns") to number (1<<0) exist?

I don't recall why I chose to add setters/getters for individual output
flags instead of expecting users to do bit-fiddling. Maybe the latter is
not as common among Python users. :)

On the other hand, things are a bit inconsistent already, see
set_debug() method. 

Maybe we could turn __{get,set}_output_flag() public and make them
accept an array of strings or numbers just like set_debug()? If you
then adjust your input flag API accordingly, things become consistent
(enough?), without breaking existing users.

FWIW, I find

| ctx.set_output_flags(["reversedns", "stateless"])

nicer than

| ctx.set_output_flags(REVERSEDNS | STATELESS)

at least with a Python hat on. WDYT?

Cheers, Phil

  reply	other threads:[~2023-07-14  9:59 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-10 17:46 [nft PATCH] nftables: add flag for nft context to avoid blocking getaddrinfo() Thomas Haller
2023-07-10 17:58 ` Pablo Neira Ayuso
2023-07-14  8:48   ` [nft v2 PATCH 1/3] nftables: add input flags for nft_ctx Thomas Haller
2023-07-14  8:48     ` [nft v2 PATCH 2/3] nftables: add input flag NFT_CTX_INPUT_NO_DNS to avoid blocking getaddrinfo() Thomas Haller
2023-07-14 10:07       ` Phil Sutter
2023-07-18  9:12         ` Thomas Haller
2023-07-14  8:48     ` [nft v2 PATCH 3/3] py: add input_{set,get}_flags() API to helpers Thomas Haller
2023-07-14  9:59       ` Phil Sutter [this message]
2023-07-18 10:07         ` Thomas Haller
2023-07-14 10:16     ` [nft v2 PATCH 1/3] nftables: add input flags for nft_ctx Phil Sutter
2023-07-18  9:05       ` Thomas Haller
2023-07-18  9:33         ` Phil Sutter
2023-07-18 10:31           ` Thomas Haller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZLEcjSPnc3PoN57E@orbyte.nwl.cc \
    --to=phil@nwl.cc \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=thaller@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.