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 AutoDetectParser
(plus DefaultDetector), while TikaConfig will by default create a
DefaultParser?
In my specific case, my class is accepting a TikaConfig object, which
may or may not be the default one (depending on the caller), and is
then creating a DefaultDetector and using that. It struck me that
mirroring the parser case might make sense
Have you considered passing a Tika instance instead of TikaConfig?
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 the same
Nick
