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 AF9D69E473 for ; Mon, 27 Nov 2023 13:02:43 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 8B4C86D42 for ; Mon, 27 Nov 2023 13:02:13 +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, 27 Nov 2023 13:02:13 +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 C663844BED for ; Mon, 27 Nov 2023 13:02:12 +0100 (CET) Message-ID: <992d0e2d-d3ec-4b2b-be91-79598712c502@proxmox.com> Date: Mon, 27 Nov 2023 13:02:11 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-GB-large To: Proxmox Backup Server development discussion , Dominik Csapak References: <20230801092954.1686860-1-d.csapak@proxmox.com> <20230801092954.1686860-4-d.csapak@proxmox.com> <6d286eab-604e-408a-b0d1-8ba5990af97f@proxmox.com> <895e307e-94f7-45d2-b094-f4fe464d4ae9@proxmox.com> <13828147-47a3-44dd-9bc3-0451038c2a56@proxmox.com> <7d00eb4a-bb62-45a7-895b-18484f51f0cf@proxmox.com> From: Thomas Lamprecht In-Reply-To: <7d00eb4a-bb62-45a7-895b-18484f51f0cf@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.062 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-backup 3/3] ui: datastore content: add action to show upload statistics 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, 27 Nov 2023 12:02:43 -0000 On 27.11.23 11:33, Dominik Csapak wrote: > On 11/27/23 11:27, Thomas Lamprecht wrote: >> Without an in-depth analysis, I think I'd prefer that slightly >> more, especially as the maintenance cost of that extra endpoint >> should be rather negligible (if there's a good API endpoint path >> to put it in, as that sometimes seems to be the harder part ^^) >> >> And yes, we could then show all the possible data about a >> snapshot, even if some of that is currently already included in >> the content tree. > > looking at the code, there really is not much more info about > the backups than what we already have in the tree > (at least not cheap ones from the manifest etc) > > the only info we have that is missing from the snapshotlistitem > is the group comment, the key fingerprint and the upload statistics, > so i'm asking myself if that is really worth a seperate api call... Not sure if I'd use the abundance of info in an bloated API call as "excuse" to not add a new one, but further bloat the existing one. Remember that we want to do a (streaming) API endpoint that returns nested objects for the datastore content, where we might want to avoid parsing each manifest, for that it might be useful It might also be useful for external API users that just want to get the info of one snapshot without the huge cost of reading all. And it might be also useful for having more options for a potential rework of the datastore content UI, e.g., moving comment editing into that and some other info or even (lesser used) actions too, that then either isn't added to the new endpoint, or one can opt-out for the current one. Note also that a minimal stats entry , e.g.: "upload-statistic":{"count":0,"size":0,"compressed-size":0,"duplicates":0} Total to 75 bytes, so for an actual realistic one 100 bytes seems reasonable, and while transport compression will help, one still needs to have all that in (browser) memory, not a huge cost, but again going into the direction we rather want to reverse from. Did you thought about the new endpoint with above in mind? I mean sure, above includes a few rather far future looking assumptions, but not sure how we ever get away from the current design if we only ever add on top, as each specifically checked cost own its own was small (it adds up, on multiple levels).