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 5E82B1FF183 for ; Wed, 27 Aug 2025 11:02:36 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 800D514458; Wed, 27 Aug 2025 11:02:37 +0200 (CEST) Message-ID: <963303ac-4794-4b9f-83c5-04101f29904c@proxmox.com> Date: Wed, 27 Aug 2025 11:02:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta To: Maximiliano Sandoval References: <20250813124347.452585-1-m.sandoval@proxmox.com> <917c568b-5a3d-466d-bbfb-87c20930e765@proxmox.com> Content-Language: de-DE, en-US From: Thomas Lamprecht In-Reply-To: X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1756285318326 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.031 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 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pbs-devel] [PATCH proxmox v2 0/3] fix #6161: time: Split parse_time_spec parser into two 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: Proxmox Backup Server development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pbs-devel-bounces@lists.proxmox.com Sender: "pbs-devel" On 27/08/2025 10:40, Maximiliano Sandoval wrote: >> What about the backward compat concerns from Dominik and Fiona, I see >> nothing written anywhere in this series addressing them, or did I just >> overlooked that? >> >> Could we treat only serializing strict and deserializing not? > I am not sure if it is possible or something we do in general. We would > need to be strict when de-serializing from the web UI (to prevent wrong > entries from reaching the configuration file) but be more lenient when > de-serializing from the configuration file. > Yes, that's the idea ;-) It is a pattern we employed quite a few times in the past already. I.e., accept and directly map legacy variants to the "good format" on parse, then when it gets serialized out again it will be automatically in the modern "correct" format. As all that was parsed got transformed to new one can safely block any legacy variant on serialization, as there such old variants must come from the API then. Rejecting this in the UI already is rather extra convenience that is nice to have but not a bare necessity. _______________________________________________ pbs-devel mailing list pbs-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel