[Xapian-tickets] [Xapian] #569: omindex --help text for -F misleading

[Xapian]

#569: omindex --help text for -F misleading
--------------------+-----------------------------
 Reporter:  catkin  |             Owner:  olly
     Type:  defect  |            Status:  assigned
 Priority:  normal  |         Milestone:  1.4.x
Component:  Omega   |           Version:  1.2.5
 Severity:  normal  |        Resolution:
 Keywords:          |        Blocked By:
 Blocking:          |  Operating System:  All
--------------------+-----------------------------
Changes (by olly):

 * milestone:  1.3.4 => 1.4.x


Comment:

 [38189b9a81c5c4c47d56692660dbb749e83c00b4/git] added a file for the
 extension to mimetype mappings, which is used to generate code and docs.
 This means that these generated tables now exactly match the code
 (previously there was a risk they'd get out of step when a new type was
 added, or some handling changed).

 We can't currently generate exactly what's in the table in the attachment
 - I'm not sure that's what we should aim for, but it would be nice to at
 least be able to say what's built in, and what needs which external
 commands.  Not sure what "Automatic" means though...

 But that part seems trickier to achieve - the external commands which are
 handled via `Filter` objects (in current git master, see
 `index_add_default_filters()` in `index_file.cc`) could easily be pulled
 out into a text file we generated code and docs from, but types handled
 internally (e.g. `application/x-abiword`) and those via external commands
 which need more complex handling (e.g. `application/postscript`) are
 harder to extract in this way.

 But it doesn't make sense to hold up 1.4.0 for the rest of this - these
 changes are essentially implementation details.

 james said:
 > I wonder if that should be a step towards having a system-level
 configuration file for default mappings, that can then be modified in a
 CLI invocation? (Would then require a new CLI option to list out the
 default mappings.)

 Currently I'm generating code from this file at compile-time, rather than
 parsing it at run-time.

 We could probably load such data from a config file instead, though it
 needs thought about what's actually useful - system-wide setting of
 filters isn't necessarily what's wanted, and a system-wide file would have
 to be root-owned (since it specifies commands that get implicitly run by
 any user invoking omindex).

--
Ticket URL: <http://trac.xapian.org/ticket/569#comment:12>
Xapian <http://xapian.org/>
Xapian