Re: [pbs-devel] [PATCH proxmox-backup 3/3] ui: datastore content: add action to show upload statistics

[Thomas Lamprecht <t.lamprecht@proxmox.com>]

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).