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.. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
