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 D5EC29E4A8 for ; Mon, 27 Nov 2023 13:08:58 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id B91256DF6 for ; Mon, 27 Nov 2023 13:08:58 +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:08:58 +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 D851C44BEB; Mon, 27 Nov 2023 13:08:57 +0100 (CET) Message-ID: <992d59dc-8b6c-4c74-9ab0-2d1d5087e2b3@proxmox.com> Date: Mon, 27 Nov 2023 13:08:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Content-Language: en-US To: Thomas Lamprecht , Proxmox Backup Server development discussion 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> <992d0e2d-d3ec-4b2b-be91-79598712c502@proxmox.com> From: Dominik Csapak In-Reply-To: <992d0e2d-d3ec-4b2b-be91-79598712c502@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.017 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:08:58 -0000 On 11/27/23 13:02, Thomas Lamprecht wrote: > 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). you are absolutely right, bloating the existing one even further is going into the wrong direction, i'll add a new api endpoint for snapshot information