public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: "Frank Ch. Eigler" <fche@redhat.com>
To: Mark Wielaard <mark@klomp.org>
Cc: elfutils-devel@sourceware.org
Subject: Re: [Bug debuginfod/27277] Describe retrieved files when verbose
Date: Wed, 29 Sep 2021 17:28:47 -0400	[thread overview]
Message-ID: <20210929212847.GA11484@redhat.com> (raw)
In-Reply-To: <599234fd5a36629b580d0a615ac069835295111f.camel@klomp.org>

Hi -

> [...]
> And if I understand your comments above correctly, you would rather see
> a function like const char* debuginfod_get_url (debuginfod_client
> *client); but for any headers. 

Correct.

> Would such a headers call be only be accessible during
> debuginfod_progressfn_t callback or would it retain the headers so
> they can be found after a debuginfod_find_* call (as long as
> debuginfod_end hasn't been called on the client handle)?

Like _url(), it'd would persist the value until the client is deleted.


> Personally I don't really like an interface that relies on the program
> having to parse somewhat arbitrary strings. I can see how it is useful
> in verbose mode for the user to see the headers to know what is going
> on (which we have now). 

The problem with what we have now, with $DEBUGINFOD_VERBOSE, is that
the amount of output is huge.  It is a debugging level trace.  It's
not consumable by non-expert users OR by software.

> But if the program needs to make any policy decisions then what do
> we guarantee about the provided header strings?

The simplest thing to do is simply to save whatever we fetched and
present it verbatim.  Parsing one-line "key: value" HTTP headers is
not that difficult.  We could -add- a few headers in order to provide
guarantees, but that's not necessary.  (We should catch up with
documenting the headers that debuginfod is known to send.)

But "programs making policy decisions" is not the only use case: what
about where a user would like to get a glance at that metadata, and
not all the other $DEBUGINFOD_VERBOSE firehose?  They could ALMOST do
it themselves via "% curl -I -i $URL", except $URL is synthesized and
competitively tie-broken between $DEBUGINFOD_URLS.


- FChE


  reply	other threads:[~2021-09-29 21:28 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-04 18:54 Noah Sanci
2021-08-05 15:13 ` Mark Wielaard
2021-08-05 16:54   ` Frank Ch. Eigler
2021-08-06 10:04     ` Mark Wielaard
2021-08-06 18:54       ` Frank Ch. Eigler
2021-08-09  9:25         ` Mark Wielaard
2021-08-23 15:11           ` Noah Sanci
2021-08-24  8:18             ` Mark Wielaard
2021-08-27 18:38               ` Noah Sanci
2021-09-08 20:56                 ` Mark Wielaard
2021-09-10 18:22                   ` Noah Sanci
2021-09-12 19:08                     ` Mark Wielaard
2021-09-13 20:07                       ` Noah Sanci
2021-09-16 10:50                         ` Mark Wielaard
2021-09-22 20:33           ` Frank Ch. Eigler
2021-09-29 14:55             ` Mark Wielaard
2021-09-29 21:28               ` Frank Ch. Eigler [this message]
2021-10-05 14:28                 ` Mark Wielaard
2022-07-14 15:32                   ` Noah Sanci
2022-08-04 13:12                     ` Mark Wielaard
     [not found]                       ` <CAJXA7qg09YkxK-NRQ31Hem0+54Us=jYC5+1siPSbHangx=SCow@mail.gmail.com>
2022-08-08 14:35                         ` Mark Wielaard
2021-08-25 18:08 Noah Sanci
2021-09-08 15:01 ` Mark Wielaard

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=20210929212847.GA11484@redhat.com \
    --to=fche@redhat.com \
    --cc=elfutils-devel@sourceware.org \
    --cc=mark@klomp.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).