Re: PATCH: Bug debuginfod/29472 followup

["Frank Ch. Eigler" <fche@redhat.com>]

Hi -

> Are you sure the interface is correct? 

Hard to be sure, so it's left generalized.  The APIs would be
unchanged if future search strategies are added (or subtracted);
they'd affect the choice of acceptable KEY strings.

We know we want glob patterns over executable file names.  I've seen
cases where an exact match query produces a different sqlite query
plan from the glob one, but not sure how much performance difference
that implies.  Searching for source files by glob/match is removed
from today's version because it doesn't run fast enough (without a new
large index).

> Is the sqlite "glob" pattern standardized? 

Yes.

> Can it be provided if the underlying server database isn't sqlite?

Yeah, in that unlikely case we undertake this someday.  glob
expressions can be translated to regular expressions, which are
themselves supported in postgres & mysql.


> I haven't read the whole diff yet. There are several refactorings
> which would be nice to see a separate patch.

One such part that occurs to me is the debuginfod_query_server() ->
init_handles() / perform_queries() subdivision.  Are there others?


> Why does debuginfod-client.c use json-c? Can't the server sent the
> json object as a normal char string? Why does the string from the
> server need to be interpreted as a json object and then turned into a
> string again?

Use of the library allows robust processing (checking & merging) of
incoming json data from multiple upstream servers.  Luckily, json-c is
a small & self-contained library.

- FChE