Re: [Bug debuginfod/27277] Describe retrieved files when verbose

[Mark Wielaard <mark@klomp.org>]

Hi Frank,

On Wed, 2021-09-22 at 16:33 -0400, Frank Ch. Eigler via Elfutils-devel
wrote:
> > from providing an interface to query what needs to be done to get
> > some file (is it in cache, can it be retieved from a remote server,
> > how
> > big is it?) I don't think providing raw http headers is that
> > interface.
> 
> Well, we have gone some way into this on PR28284, on various branches
> including nsanci/pr28284-webapi.  It's not complete, yet the "raw
> http
> headers" aspect is still there, because what headers are available is
> unpredictable.  But now this is made even more wordy by forking the
> _find_ functions into a _describe_ triplet and all the other leftover
> work elsewhere.
> 
> IMHO it's not an improvement over a single function that returns
> headers associated with the lookup.  Please let's discuss this again.

Looking at the nscanci/pr28284 branch I see the following proposed
interface for debuginfod-client:

/* The _describe_ variants of the query functions return a set of HTTP-like
   headers that would result from a new lookup.  No content is collected. 
   If successful, return zero, otherwise return a posix error code.  If
   successful, set *headers a strdup()'d copy of the headers.
   Caller must free() it later. */

int debuginfod_describe_debuginfo (debuginfod_client *client,
                                   const unsigned char *build_id,
                                   int build_id_len,
                                   char **headers);

int debuginfod_describe_executable (debuginfod_client *client,
                                    const unsigned char *build_id,
                                    int build_id_len,
                                    char **headers);

int debuginfod_describe_source (debuginfod_client *client,
                                const unsigned char *build_id,
                                int build_id_len,
                                const char *filename,
                                char **headers);

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. 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)?

Or do I misunderstand the various proposals?

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). But if the program needs to make any policy
decisions then what do we guarantee about the provided header strings?

What is the information the program really needs? I think that is a)
whether the requested file is already in cache, b) if not, whether it
can be retrieved from a server, and c) if so how big it is and/or how
many bytes need to be transferred from the server.

If the above seems reasonable information to provide to the program
then we can design a debuginfo-client interface based on that. Which
might or might not include the full headers to the program. But I might
be missing some important data or misinterpret the goal of the new
interface/information provided to the program.

Cheers,

Mark