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

[Dominik Csapak]

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