From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <e@80x24.org>
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-ASN:  
X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,AWL,BAYES_00
	shortcircuit=no autolearn=ham autolearn_force=no version=3.4.1
Received: from localhost (dcvr.yhbt.net [127.0.0.1])
	by dcvr.yhbt.net (Postfix) with ESMTP id 075E31F597;
	Wed, 18 Jul 2018 16:31:39 +0000 (UTC)
Date: Wed, 18 Jul 2018 16:31:39 +0000
From: Eric Wong <e@80x24.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: meta@public-inbox.org
Subject: Re: [PATCH 3/3] SearchIdx: Allow the amount of indexing be configured
Message-ID: <20180718163139.sqgr7im572bnlrgg@dcvr>
References: <87a7qpjve8.fsf@xmission.com>
 <20180717233058.30820-3-ebiederm@xmission.com>
 <20180718102233.jt4loti4k3x3wkp7@whir>
 <87bmb4ilfc.fsf@xmission.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <87bmb4ilfc.fsf@xmission.com>
List-Id: <meta.public-inbox.org>

"Eric W. Biederman" <ebiederm@xmission.com> wrote:
> Eric Wong <e@80x24.org> writes:
> 
> > "Eric W. Biederman" <ebiederm@xmission.com> wrote:
> >> This adds a new inbox configuration option 'indexlevel' that can take
> >> the values 'positions', 'terms', and 'over'.
> >
> > The names of these user-facing configuration variables aren't
> > obviously "levels" at all; especially to people not familiar
> > with Xapian or public-inbox internals.
> >
> > As for "over", at least it should be spelled out "overview";
> > but really, I would much prefer something which wouldn't require
> > consulting the manual for explanations, such as:
> >
> > 	'full', 'medium', 'minimal'
> 
> Do you mind the config option name indexlevel?

'indexlevel' is fine.  I originally had something along the
lines of 'type' in mind (e.g. 'indextype'); but maybe 'level'
is more obvious and requires less documentation.

> I don't mind changing the names I just needed some name and
> those names were present.
> 
> > Where it's obvious which one sits relative to the others.
> >
> > That wouldn't tie our user-facing configuration to our internal
> > choices or terminology used by Xapian, either.  I'm pretty happy
> > with Xapian; but it may be worth exploring other search engines
> > at some point...
> >
> >> --- a/lib/PublicInbox/SearchIdx.pm
> >> +++ b/lib/PublicInbox/SearchIdx.pm
> >> @@ -47,6 +47,7 @@ sub git_unquote ($) {
> >>  
> >>  sub new {
> >>  	my ($class, $ibx, $creat, $part) = @_;
> >> +	my $levels = qr/(positions|terms|over)/;
> >
> > Please anchor matches so they match expected strings exactly.
> > It lets typos be caught and makes life easier for 3rd-party
> > tools and implementations if we're stricter in what we accept.
> > Captures aren't necessary, so '?:' can be used:
> >
> > 	qr/\A(?:full|medium|minimal)\z/
> >
> > Same comment applies to patch 2/3
> 
> Good point.  I wish I knew a way so I didn't have to repeat the test
> so often.  But getting the user space interface correct is the first
> step then we can optimize if need be.

As in repeating the string comparison?  Perhaps it could be
mapped to different subroutine calls:

sub do_index_text { ... }
sub do_index_text_without_positions { ... }
sub do_overview { ... }

my %INDEX_LEVEL = (
	full => *do_index_text,
	medium => *do_index_text_without_positions,
	minimal => *do_overview,
);

	$self->{index_cb} = $INDEX_LEVEL{$ibx->{indexlevel}};
	defined $self->{index_cb} or die "invalid indexlevel\n";