From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <e@80x24.org>
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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.2
Received: from localhost (dcvr.yhbt.net [127.0.0.1])
	by dcvr.yhbt.net (Postfix) with ESMTP id 6BA0D1F462;
	Sat, 15 Jun 2019 20:37:19 +0000 (UTC)
Date: Sat, 15 Jun 2019 20:37:19 +0000
From: Eric Wong <e@80x24.org>
To: =?utf-8?Q?Nicol=C3=A1s_Ojeda_B=C3=A4r?= <n.oje.bar@gmail.com>
Cc: meta@public-inbox.org
Subject: Re: public-inbox-httpd feature request: sort oldest-first
Message-ID: <20190615203719.5un64ihnkf7b74gf@dcvr>
References: <CAPunWhB=EEfCpiecKKNPMwF9XuQDp1yM_iugA+W2S6pFJ5YPFw@mail.gmail.com>
 <20180314071304.GA17978@dcvr>
 <CAPunWhD85aNDEg1Uk_fc1-a9zP+_C431y0YHD0MUHq4JVvV22w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAPunWhD85aNDEg1Uk_fc1-a9zP+_C431y0YHD0MUHq4JVvV22w@mail.gmail.com>
List-Id: <meta.public-inbox.org>

Nicolás Ojeda Bär <n.oje.bar@gmail.com> wrote:
> On Wed, Mar 14, 2018 at 8:13 AM, Eric Wong <e@80x24.org> wrote:
> > Nicolás Ojeda Bär <n.oje.bar@gmail.com> wrote:
> >> Unless I missed something there does not seem to be a way to sort the
> >> message list oldest-to-newest. A little arrow somewhere to invert the
> >> order would be nice to have.
> >
> > Right; it's always favors newest messages.  We usually find
> > newer messages more relevant and also git packs are optimized
> > for newer data.
> >
> > I'll take your request into consideration, but am currently
> > against this:

So I've realized reversing results can be faster than "git blame"
in some cases, so I've implemented this:

  https://public-inbox.org/meta/20190615202342.7730-1-e@80x24.org/T/

> > I don't want to go down the path of making the WWW interface too
> > complex or trying to satisfy everybody with it.  User interface
> > is a PERSONAL choice and I want it to remain that way.

So I didn't state this before; but one of my concerns was about
extra parameters and inconsistent ordering leading to duplicate
cache entries (in either the client or varnish).

So I managed to overload the "o=" paramter to use negative
values, which makes sense to users of Perl (and similar)
languages which allow negative array indices to look backwards.

I'm actually regretting making "x=" a separate parameter,
instead of just replacing "q="...

So I might also start 301-ing search requests to enforce a
consistent ordering for cache-friendliness...

> I share this point of view. Having said that, _personally_ I still
> feel reverse date ordering is an important feature to have in the web
> interface.

Fair enough.  I'm considering developing some sort of REST API or
just for search; since their's no provision for it in NNTP; and
IMAP search capabilities are too limited.