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) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 2EA519E39F for ; Mon, 27 Nov 2023 11:33:48 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 1098D52E4 for ; Mon, 27 Nov 2023 11:33:18 +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:33:17 +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 22B8244BBE; Mon, 27 Nov 2023 11:33:17 +0100 (CET) Message-ID: <7d00eb4a-bb62-45a7-895b-18484f51f0cf@proxmox.com> Date: Mon, 27 Nov 2023 11:33:14 +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> From: Dominik Csapak In-Reply-To: <13828147-47a3-44dd-9bc3-0451038c2a56@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 10:33:48 -0000 On 11/27/23 11:27, Thomas Lamprecht wrote: > 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. 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...