Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: Naming ETag files?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Timothe Litt <litt_at_acm.org>
Date: Sun, 15 Jan 2023 13:46:05 -0500
On 15-Jan-23 13:04, Paul Gilmartin via curl-users wrote:
> On 1/15/23 05:19:32, Timothe Litt via curl-users wrote:
>> ...
>> If the filesystem supports extended attributes, an even better place
>> would be to store the etag there, since in that case, moving,
>> copying, renaming would automagically ensure that the etag is carried
>> along. Linux xattr, Mac forks, NTFS 'streams', etc..
>
> Interesting. The Mac and Linux xattr commands have a useful compatible
> overlap. So I could download with:
> --etag-save tempfile.ETag
> tnen:
> xattr -w user.aETag "$( cat tempfile.ETag )" downloaded-resource
>
> ... and reverse the process for --etag-compare for the next conditional
> download.
>
[and delete the tempfile. And for mult-file downloads, handle each file.]
So: Yes, but it would be much better for curl to do it automagically.
Users shouldn't have to work hard or be expert on the underlying
technologies to have a good experience. I'm all for flexibility for
experts, but the defaults ought to provide the best performance for as
many cases as possible. That's why in an ideal world, I'd prefer to
obsolete the --etag-save and --etag-compare switches and have curl do
the right things. (dotfiles, extended attributes.) Plus curl could hide
the details of xattrs mac vs. linux vs solaris vs windows vs vms vs
freebsd vs aix vs... And which filesystems support xattrs - it's not
just per-os. Falling back to a dotfile would keep things consistent.
--no-etag would then let the experts experiment with options and test.
Progress isn't best measured in how many options can be added to express
intent; rather, how few need to be specified to get the best results.
The options should be reserved for exceptions when the best default
action needs to b changed (as in testing), or cases where curl doesn't
have the information necessary to make the best choice.
This doesn't just apply to curl, though its explosion of options is a
pretty good example of how adding options with each feature can lose
sight of making the user experience simple.
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
Received on 2023-01-15
Date: Sun, 15 Jan 2023 13:46:05 -0500
On 15-Jan-23 13:04, Paul Gilmartin via curl-users wrote:
> On 1/15/23 05:19:32, Timothe Litt via curl-users wrote:
>> ...
>> If the filesystem supports extended attributes, an even better place
>> would be to store the etag there, since in that case, moving,
>> copying, renaming would automagically ensure that the etag is carried
>> along. Linux xattr, Mac forks, NTFS 'streams', etc..
>
> Interesting. The Mac and Linux xattr commands have a useful compatible
> overlap. So I could download with:
> --etag-save tempfile.ETag
> tnen:
> xattr -w user.aETag "$( cat tempfile.ETag )" downloaded-resource
>
> ... and reverse the process for --etag-compare for the next conditional
> download.
>
[and delete the tempfile. And for mult-file downloads, handle each file.]
So: Yes, but it would be much better for curl to do it automagically.
Users shouldn't have to work hard or be expert on the underlying
technologies to have a good experience. I'm all for flexibility for
experts, but the defaults ought to provide the best performance for as
many cases as possible. That's why in an ideal world, I'd prefer to
obsolete the --etag-save and --etag-compare switches and have curl do
the right things. (dotfiles, extended attributes.) Plus curl could hide
the details of xattrs mac vs. linux vs solaris vs windows vs vms vs
freebsd vs aix vs... And which filesystems support xattrs - it's not
just per-os. Falling back to a dotfile would keep things consistent.
--no-etag would then let the experts experiment with options and test.
Progress isn't best measured in how many options can be added to express
intent; rather, how few need to be specified to get the best results.
The options should be reserved for exceptions when the best default
action needs to b changed (as in testing), or cases where curl doesn't
have the information necessary to make the best choice.
This doesn't just apply to curl, though its explosion of options is a
pretty good example of how adding options with each feature can lose
sight of making the user experience simple.
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-users Etiquette: https://curl.se/mail/etiquette.html
- application/pgp-signature attachment: OpenPGP digital signature