From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 2020E1FF39D for ; Tue, 11 Jun 2024 16:30:23 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id B3EF0F72; Tue, 11 Jun 2024 16:30:58 +0200 (CEST) Mime-Version: 1.0 Date: Tue, 11 Jun 2024 16:30:25 +0200 Message-Id: From: "Shannon Sterz" To: "Wolfgang Bumiller" X-Mailer: aerc 0.17.0-69-g65571b67d7d3-dirty References: <20240610154214.356689-1-s.sterz@proxmox.com> <20240610154214.356689-5-s.sterz@proxmox.com> In-Reply-To: X-SPAM-LEVEL: Spam detection results: 0 AWL -0.053 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] [PATCH proxmox 4/5] access: factor out user config and cache handling 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: , Reply-To: Proxmox Backup Server development discussion Cc: pbs-devel@lists.proxmox.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pbs-devel-bounces@lists.proxmox.com Sender: "pbs-devel" On Tue Jun 11, 2024 at 3:07 PM CEST, Wolfgang Bumiller wrote: > On Mon, Jun 10, 2024 at 05:42:13PM GMT, Shannon Sterz wrote: > > this commit factors out the user config as well as the shared memory > > based config version caching mechanism. this makes it necessary that > > users of this crate provide the product name and a reference to a > > shared memory location as well. > > Given that we have more values in the shared memory in PBS I wonder if > we should instead provide the `get` and `increment` methods to init > (directly as `fn` or via a trait). yeah, that might make sense to hand that over via a trait and implement the actually shared memory portion either in the project itself or have a generic implementation that we can adapt to each project. not entirely sure what the best way is, though. if we do implement some kind of generic shared memory cache generation counter, where would live ideal? _______________________________________________ pbs-devel mailing list pbs-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel