Hi All
As of a month or two back, now have a DefaultDetector, which does nifty
service loading to find all the available detectors. This replaces the
ContainerAwareDetector, and works in very much the same way as the default
parser does.
Would it make sense to add a getDetector() method to T
Hi,
On Mon, Oct 17, 2011 at 2:32 PM, Nick Burch wrote:
> Would it make sense to add a getDetector() method to TikaConfig to mirror
> the parser one? It's only a few lines of code without it, but it seems to me
> that it'd make things simpler and cleaner if it was there. Thoughts?
Why not just us
On Mon, 17 Oct 2011, Jukka Zitting wrote:
On Mon, Oct 17, 2011 at 2:32 PM, Nick Burch wrote:
Would it make sense to add a getDetector() method to TikaConfig to mirror
the parser one? It's only a few lines of code without it, but it seems to me
that it'd make things simpler and cleaner if it was
OK, I see the point.
If we do add such a TikaConfig.getDetector() method, then the
equivalent code in the Tika(TikaConfig) constructor should be replaced
to call that method to avoid duplication.
> In my specific case, my class is accepting a TikaConfig object, which may or
> may not be
On Tue, 18 Oct 2011, Jukka Zitting wrote:
If we do add such a TikaConfig.getDetector() method, then the equivalent
code in the Tika(TikaConfig) constructor should be replaced to call that
method to avoid duplication.
Sure
Also, is there a reason why the Tika facade creates an
Hi,
On Tue, Oct 18, 2011 at 11:07 AM, Nick Burch wrote:
> Also, is there a reason why the Tika facade creates an AutoDetectParser
> (plus DefaultDetector), while TikaConfig will by default create a
> DefaultParser?
Not really, we should unify also that code.
> For my case, the class already tak
On Tue, 18 Oct 2011, Jukka Zitting wrote:
For my case, the class already takes a TikaConfig object, as it sometimes
needs to do mimetype heirarchy and similar related stuff. Rather than
wrapping that internally in a Tika object, it occured to me that parser and
detector should possibly be made th
