From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (wildebeest.demon.nl [212.238.236.112]) by sourceware.org (Postfix) with ESMTPS id 5500F3858C60 for ; Wed, 29 Sep 2021 14:55:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5500F3858C60 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from tarox.wildebeest.org (83-87-18-245.cable.dynamic.v4.ziggo.nl [83.87.18.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 0B38B3000A0A; Wed, 29 Sep 2021 16:55:06 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id AEE12413CD4A; Wed, 29 Sep 2021 16:55:05 +0200 (CEST) Message-ID: <599234fd5a36629b580d0a615ac069835295111f.camel@klomp.org> Subject: Re: [Bug debuginfod/27277] Describe retrieved files when verbose From: Mark Wielaard To: "Frank Ch. Eigler" Cc: elfutils-devel@sourceware.org Date: Wed, 29 Sep 2021 16:55:05 +0200 In-Reply-To: <20210922203331.GC13236@redhat.com> References: <20210805165402.GD4195@redhat.com> <35f2073dfeed8f008d42a78bf60b7efcf13164eb.camel@klomp.org> <20210806185459.GE4195@redhat.com> <9ac621fee207ef233873c40843b3d34ced9019cc.camel@klomp.org> <20210922203331.GC13236@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-10.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2021 14:55:09 -0000 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. >=20 > 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. >=20 > 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.= =20 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