Re: [pve-devel] [PATCH manager v8 1/2] fix #4849: api: download to storage: automatically dectect and configure compression

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

Am 26/09/2023 um 16:54 schrieb Philipp Hufnagl:
> On 9/26/23 16:23, Thomas Lamprecht wrote:
>> Am 26/09/2023 um 14:25 schrieb Philipp Hufnagl:
>>> On 9/26/23 12:56, Thomas Lamprecht wrote:
>>>> while this is already applied, some comments inline, for a possible next
>>>> time, and also the big
>>>> question if this is even required, after all I can just check the few
>>>> compression algorithms easily in the frontend, i.e., offloading a simple
>>>> string regex match to the backend seems rather odd to me..
>>> The problem with that is that the point where the iso is stored might
>>> not be accessible for the client. If it is done by the PVE, it might
>>> resolve the url differently.
>>
>> I'm not sure if I understand, I thought that's why we made the link
>> metadata- query API in the first place (which I obv. do not want to drop
>> in general)?
>>
>> As we got the correct (from the PVE node's POV) resolved filename
>> returned by the metadata query API, so we can just do the regex string
>> match for detecting a possible compression file extension on that in the
>> frontend after that API call returns.
>>
> 
> Yes that would have been possible, however it would not have saved an
> API call since the call is needed anyway. I did it there because I
> considered it a cleaner solution to do all handling of metadata in one
> place rather then returning a "filename" that has to be further
> processed in "filename" and "compression".

I never implied that it would save an API call, just that it would
avoid adding unecesarry parameters and return values, bloating up
our API schema for a trivial string match that any client can do
themselves..