From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <t.lamprecht@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 D3DFE72776; Tue, 13 Apr 2021 09:29:12 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id CA1D2275AC; Tue, 13 Apr 2021 09:29:12 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [212.186.127.180]) (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 id 5FF86275A2; Tue, 13 Apr 2021 09:29:12 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 208C14205F; Tue, 13 Apr 2021 09:29:12 +0200 (CEST) Message-ID: <c7facbe9-5be5-ffa1-cf23-3b0439495df5@proxmox.com> Date: Tue, 13 Apr 2021 09:29:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:88.0) Gecko/20100101 Thunderbird/88.0 Content-Language: en-US To: Dominik Csapak <d.csapak@proxmox.com>, Proxmox Backup Server development discussion <pbs-devel@lists.proxmox.com>, Stefan Reiter <s.reiter@proxmox.com>, pve-devel@lists.proxmox.com References: <20210412153252.22652-1-s.reiter@proxmox.com> <20210412153252.22652-2-s.reiter@proxmox.com> <3e6c8636-f44a-6c23-b782-d567f2446fff@proxmox.com> <d5cce679-33a1-1c0c-35ec-c6739a339b07@proxmox.com> From: Thomas Lamprecht <t.lamprecht@proxmox.com> In-Reply-To: <d5cce679-33a1-1c0c-35ec-c6739a339b07@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL -0.042 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.001 Looks like a legit reply (A) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [pbs-devel] applied: [PATCH proxmox-backup 2/2] api/datastore: allow pxar file download of entire archive X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/> List-Post: <mailto:pve-devel@lists.proxmox.com> List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe> X-List-Received-Date: Tue, 13 Apr 2021 07:29:12 -0000 On 13.04.21 09:23, Dominik Csapak wrote: > On 4/13/21 08:39, Thomas Lamprecht wrote: >> But that API is definitively weird in general... >=20 > just fyi >=20 >> >> 1. old style API definition, should use the #[api()] macro instead >=20 > the api macro cannot handle AsyncHttp api calls (yet?), but this is req= uired for the stream that shoudn't be a hard problem, it's a macro it can expand to whatever..= >> 2. perly "params: Value", yeah, no thanks. >=20 > a result from above, without api macro no de-structuring of parameters see above >=20 >> 3. hard coded return stream type, one should be able to download also = a single >> =C2=A0=C2=A0=C2=A0 file as zip, and we knew that we wanted .tar then t= oo, so not providing an >> =C2=A0=C2=A0=C2=A0 param for that is weird. >=20 > we always can add as much, but until now, generating a zip for a single= > file was not really sensible Compression isn't the only benefit a encapsulation like an archive format= =2E >=20 >> 4. accessed via /json/ path but never returns json >=20 > all api calls need a formatter to call, should we add a > new one for download type? I know that all paths have a formatter, does not validates misusing JSON for something completely different ;) From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <t.lamprecht@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 D3DFE72776; Tue, 13 Apr 2021 09:29:12 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id CA1D2275AC; Tue, 13 Apr 2021 09:29:12 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [212.186.127.180]) (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 id 5FF86275A2; Tue, 13 Apr 2021 09:29:12 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 208C14205F; Tue, 13 Apr 2021 09:29:12 +0200 (CEST) Message-ID: <c7facbe9-5be5-ffa1-cf23-3b0439495df5@proxmox.com> Date: Tue, 13 Apr 2021 09:29:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:88.0) Gecko/20100101 Thunderbird/88.0 Content-Language: en-US To: Dominik Csapak <d.csapak@proxmox.com>, Proxmox Backup Server development discussion <pbs-devel@lists.proxmox.com>, Stefan Reiter <s.reiter@proxmox.com>, pve-devel@lists.proxmox.com References: <20210412153252.22652-1-s.reiter@proxmox.com> <20210412153252.22652-2-s.reiter@proxmox.com> <3e6c8636-f44a-6c23-b782-d567f2446fff@proxmox.com> <d5cce679-33a1-1c0c-35ec-c6739a339b07@proxmox.com> From: Thomas Lamprecht <t.lamprecht@proxmox.com> In-Reply-To: <d5cce679-33a1-1c0c-35ec-c6739a339b07@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL -0.042 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.001 Looks like a legit reply (A) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pbs-devel] applied: [PATCH proxmox-backup 2/2] api/datastore: allow pxar file download of entire archive 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: Tue, 13 Apr 2021 07:29:12 -0000 On 13.04.21 09:23, Dominik Csapak wrote: > On 4/13/21 08:39, Thomas Lamprecht wrote: >> But that API is definitively weird in general... >=20 > just fyi >=20 >> >> 1. old style API definition, should use the #[api()] macro instead >=20 > the api macro cannot handle AsyncHttp api calls (yet?), but this is req= uired for the stream that shoudn't be a hard problem, it's a macro it can expand to whatever..= >> 2. perly "params: Value", yeah, no thanks. >=20 > a result from above, without api macro no de-structuring of parameters see above >=20 >> 3. hard coded return stream type, one should be able to download also = a single >> =C2=A0=C2=A0=C2=A0 file as zip, and we knew that we wanted .tar then t= oo, so not providing an >> =C2=A0=C2=A0=C2=A0 param for that is weird. >=20 > we always can add as much, but until now, generating a zip for a single= > file was not really sensible Compression isn't the only benefit a encapsulation like an archive format= =2E >=20 >> 4. accessed via /json/ path but never returns json >=20 > all api calls need a formatter to call, should we add a > new one for download type? I know that all paths have a formatter, does not validates misusing JSON for something completely different ;)