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 E181F9E399 for ; Mon, 27 Nov 2023 11:27:42 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id BCCC350E1 for ; Mon, 27 Nov 2023 11:27:12 +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 11:27:12 +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 E549B44B17 for ; Mon, 27 Nov 2023 11:27:11 +0100 (CET) Message-ID: <13828147-47a3-44dd-9bc3-0451038c2a56@proxmox.com> Date: Mon, 27 Nov 2023 11:27:10 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-GB-large To: Dominik Csapak , 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> From: Thomas Lamprecht In-Reply-To: <895e307e-94f7-45d2-b094-f4fe464d4ae9@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 10:27:42 -0000 On 27.11.23 11:04, Dominik Csapak wrote: >>> + getClass: (v, m, rec) => rec.data.ty === 'dir' ? 'fa fa-info-circle' : 'pmx-hidden', >> >> info-circle is not a good icon for some specific stats, i.e., not a >> general info about the backup snapshot.. A stop-watch could be nice, >> but there doesn't seem to be any, so possibly "fa-file-text-o" (a >> sheet of stat lines, so to say), not ideal too but IMO better than >> the info-circle. >> >> ps. maybe injecting some more general info like duration could be >> nice (didn't check if we even have that available already here >> though). >> >> That said maybe one could even make this an actual info dialog, >> with the stats only be one part of that, then the info-circle >> could be OK too and we'd not add a core UI element for a rather >> niche information that most won't look at often. > > here we basically have only the info we have in the grid already, > but we could provide it in a nicer way maybe: > > backup time, files (+sizes), last verification info (+link to task log), etc. Yeah, that's what I basically meant first, show the whole info a bit nicer, possibly even hide some columns of it by default then (the list is quite cramped already) > > or did you mean we add a new api endpoint that returns more info about the snapshot > altogether? (which could also make sense) I mean, then we'd not have to "shove" in the upload stats into the generic list snapshots API call, as you wrote yourself, especially if we never plan to show those inline it might make really more sense to split that, even if we'd have the manifest already read and thus in memory. 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.