[Xapian-tickets] [Xapian] #792: Add a CGI param "LOC" to indicate a path to a leaf from database_dir folder

[Xapian]

#792: Add a CGI param "LOC" to indicate a path to a leaf from database_dir folder
-------------------------+-------------------------
 Reporter:  ohallot      |             Owner:  olly
     Type:  enhancement  |            Status:  new
 Priority:  normal       |         Milestone:
Component:  Omega        |           Version:
 Severity:  normal       |        Resolution:
 Keywords:               |        Blocked By:
 Blocking:               |  Operating System:  All
-------------------------+-------------------------

Comment (by olly):

 It doesn't seem justified to disrupt existing users to address this - it's
 been this way for 20+ years, and this is the first time somebody's
 actually complained about it that I'm aware of.  Probably a few other
 people have hit it and just worked with it, and I am sympathetic to trying
 to lift the restriction.

 Changing CGI parameter names is rather disruptive - for example, it means
 bookmarked searches and scripted use stop working.  So we've so far
 generally avoided such changes, and also tried to ensure that any changes
 in meaning do something sensible with an existing bookmarked search - e.g.
 the encoding of `$filters` has evolved over time, which means incompatible
 changes to the behaviour of `xFILTERS`, but (a) we've carried code to also
 compare `xFILTERS` with what the old version would have given for
 `$filters` for a transitional period, and (b) if Omega thinks the filters
 have changes it forces the first page of results, which is generally
 reasonable (people are unlikely to intentionally bookmark page 2 of a
 search except perhaps in the short term) and also plays well with
 automated use (where you'd generally just not pass `xFILTERS` at all).

 `:` is a common separator for listing several pathnames on Unix-like
 platforms, though there doesn't seem to be a universal standard - e.g.
 Microsoft ones seem to use `;`, and ISTR classic Macs used `:` for the
 role `/` has on Unix.

 `:` might be a reasonable fixed choice if we were designing this from a
 clean slate, but I'm not sure I like the idea of suddenly changing from
 `/` to `:` - that's again a potentially disruptive change to people who
 probably don't care that they can't currently have `/` in database names.
 Fixing it as `:` would also mean that you then couldn't have `:` in a
 database name, which is currently allowed, and there are probably users
 with databases so named.

 It seems rather contrary to solve the inability to have `/` in a database
 name by disallowing some other character instead - what would we do when
 someone opens a ticket asking to allow `:` again?  Change to another fixed
 value and round and round we go until people stop complaining?

 Making it completely configurable is unnecessarily general, and some
 characters would just be a bad idea to use because they'd result in URL
 escaping (e.g. `&` -> `DB=a%26B%26c`) or just be confusing (e.g. an
 alphanumeric such as `a`), so perhaps it would be better to restrict the
 allowed choices.  `/` is compatible with current deployments, and `//` has
 the nice property of allowing any valid relative database pathname to be
 specified.  So we could allow those two and `:`.

 We already need to vet filenames for `..` (in CGI parameter `FMT` and
 arguments to `$include{}` and `$log{}`) so that's not a big deal.

--
Ticket URL: <https://trac.xapian.org/ticket/792#comment:4>
Xapian <https://xapian.org/>
Xapian