From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <d.csapak@proxmox.com>
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 <pbs-devel@lists.proxmox.com>; 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 <pbs-devel@lists.proxmox.com>; 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 <pbs-devel@lists.proxmox.com>; 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 <t.lamprecht@proxmox.com>,
Proxmox Backup Server development discussion <pbs-devel@lists.proxmox.com>
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 <d.csapak@proxmox.com>
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
<pbs-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pbs-devel>,
<mailto:pbs-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pbs-devel/>
List-Post: <mailto:pbs-devel@lists.proxmox.com>
List-Help: <mailto:pbs-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel>,
<mailto:pbs-devel-request@lists.proxmox.com?subject=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