From: Thomas Lamprecht <t.lamprecht@proxmox.com>
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
Subject: Re: [pve-devel] [pbs-devel] applied: [PATCH proxmox-backup 2/2] api/datastore: allow pxar file download of entire archive
Date: Tue, 13 Apr 2021 09:29:11 +0200 [thread overview]
Message-ID: <c7facbe9-5be5-ffa1-cf23-3b0439495df5@proxmox.com> (raw)
In-Reply-To: <d5cce679-33a1-1c0c-35ec-c6739a339b07@proxmox.com>
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...
>
> just fyi
>
>>
>> 1. old style API definition, should use the #[api()] macro instead
>
> the api macro cannot handle AsyncHttp api calls (yet?), but this is required 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.
>
> a result from above, without api macro no de-structuring of parameters
see above
>
>> 3. hard coded return stream type, one should be able to download also a single
>> file as zip, and we knew that we wanted .tar then too, so not providing an
>> param for that is weird.
>
> 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.
>
>> 4. accessed via /json/ path but never returns json
>
> 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 ;)
WARNING: multiple messages have this Message-ID
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
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
Subject: Re: [pbs-devel] applied: [PATCH proxmox-backup 2/2] api/datastore: allow pxar file download of entire archive
Date: Tue, 13 Apr 2021 09:29:11 +0200 [thread overview]
Message-ID: <c7facbe9-5be5-ffa1-cf23-3b0439495df5@proxmox.com> (raw)
In-Reply-To: <d5cce679-33a1-1c0c-35ec-c6739a339b07@proxmox.com>
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...
>
> just fyi
>
>>
>> 1. old style API definition, should use the #[api()] macro instead
>
> the api macro cannot handle AsyncHttp api calls (yet?), but this is required 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.
>
> a result from above, without api macro no de-structuring of parameters
see above
>
>> 3. hard coded return stream type, one should be able to download also a single
>> file as zip, and we knew that we wanted .tar then too, so not providing an
>> param for that is weird.
>
> 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.
>
>> 4. accessed via /json/ path but never returns json
>
> 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 ;)
next prev parent reply other threads:[~2021-04-13 7:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-12 15:32 [pve-devel] [PATCH proxmox-widget-toolkit 1/2] FileBrowser: allow downloading root folder and simplify code Stefan Reiter
2021-04-12 15:32 ` [pbs-devel] " Stefan Reiter
2021-04-12 15:32 ` [pve-devel] [PATCH proxmox-backup 2/2] api/datastore: allow pxar file download of entire archive Stefan Reiter
2021-04-12 15:32 ` [pbs-devel] " Stefan Reiter
2021-04-13 6:39 ` [pve-devel] applied: " Thomas Lamprecht
2021-04-13 6:39 ` [pbs-devel] applied: " Thomas Lamprecht
2021-04-13 7:23 ` [pve-devel] " Dominik Csapak
2021-04-13 7:23 ` Dominik Csapak
2021-04-13 7:29 ` Thomas Lamprecht [this message]
2021-04-13 7:29 ` Thomas Lamprecht
2021-04-13 7:02 ` [pve-devel] applied: [PATCH proxmox-widget-toolkit 1/2] FileBrowser: allow downloading root folder and simplify code Thomas Lamprecht
2021-04-13 7:02 ` [pbs-devel] applied: [pve-devel] " Thomas Lamprecht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c7facbe9-5be5-ffa1-cf23-3b0439495df5@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=d.csapak@proxmox.com \
--cc=pbs-devel@lists.proxmox.com \
--cc=pve-devel@lists.proxmox.com \
--cc=s.reiter@proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal