From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 16F4FB8DC2 for ; Mon, 11 Mar 2024 16:41:55 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id E44D2CB62 for ; Mon, 11 Mar 2024 16:41:24 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Mon, 11 Mar 2024 16:41:24 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 15D7248908 for ; Mon, 11 Mar 2024 16:41:24 +0100 (CET) Date: Mon, 11 Mar 2024 16:41:17 +0100 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= To: Christian Ebner , Proxmox Backup Server development discussion References: <20240305092703.126906-1-c.ebner@proxmox.com> <20240305092703.126906-3-c.ebner@proxmox.com> <1710152828.1ncysi2oe3.astroid@yuna.none> <655178535.10743.1710165023860@webmail.proxmox.com> In-Reply-To: <655178535.10743.1710165023860@webmail.proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.16.0 (https://github.com/astroidmail/astroid) Message-Id: <1710171613.7dn5zou299.astroid@yuna.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL 0.065 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pbs-devel] [RFC v2 pxar 02/36] encoder: add optional output writer for file payloads X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2024 15:41:55 -0000 On March 11, 2024 2:50 pm, Christian Ebner wrote: > On 3/11/24 14:21, Fabian Gr=C3=BCnbichler wrote: >> On March 5, 2024 10:26 am, Christian Ebner wrote: >>=20 >> should we prevent/catch this being called multiple times? >=20 > The attaching of the optional payload output being possible > at any time and even multiple times is something Dietmar noticed as > well. >=20 > I will follow his suggestion here and add this as an optional parameter > to the encoders `new` method, which will handle this better at the cost > of breaking the API. Are there objections to that? IMHO breaking the API here is fine, this whole series is not fully compatible anyway already.. and setting it once at construction time and not having a setter later on seems sensible for this, yes. >> this part here and the read counter-part in the next commit basically >> hard-code the format of this entry type, maybe that could be handled >> nicer? e.g., construct a PayloadRef here, and let that implement the >> conversion to/from data? >>=20 >> it is a pre-existing pattern here though ;) >> >=20 > Okay, will have a look on how to handle the serialization in a more > generic way, especially since the `PayloadRef` struct will be used > later in the decoder anyway (therefore already have that), so it might > make sense to e.g. have a trait for all pxar entry types to that > guarantees the serialization methods. >=20 > Is that what you had in mind here? something like that (I mean, even a simple `fn data(&self)` would be enough possibly?)