Tika facade - static or not

[Jukka Zitting]

Hi,

At first I used static methods in the Tika facade class, but then I
switched to normal instance methods to make it easier to use custom
Tika configuration. However, now I'm thinking that the original design
was probably better.

Any opinions on this? Essentially, which one of the following do you
like better:

    a) new Tika().parse(...);

    b) Tika.parse(...);

The benefit of a) over b) is that you can say: new
Tika(config).parse(...), but most of the people who need custom
configuration will probably in any case be going beyond the Tika
facade.

BR,

Jukka Zitting

[Michael Wechner]

Jukka Zitting schrieb:

> Hi,
>
> At first I used static methods in the Tika facade class, but then I
> switched to normal instance methods to make it easier to use custom
> Tika configuration. However, now I'm thinking that the original design
> was probably better.
>
> Any opinions on this? Essentially, which one of the following do you
> like better:
>
>     a) new Tika().parse(...);
>
>     b) Tika.parse(...);
>  

I assume you are refering to Tika 0.5

http://lucene.apache.org/tika/apidocs/org/apache/tika/Tika.html

right? Because so far I have only experience with
TikConfig.getParser().parse(...)
> The benefit of a) over b) is that you can say: new
> Tika(config).parse(...), but most of the people who need custom
> configuration will probably in any case be going beyond the Tika
> facade.
>  

you mean using TikaConfig.getParser().parse(...)

?

Thanks

Michael
> BR,
>
> Jukka Zitting
>  

[Mattmann, Chris A (388J)]

Hi Jukka,

My +1 for option A and B, I think it's better in the long run since configuration is an issue. All methods from option B should load default static configuration. I'd be happy to take the lead on JIRA'ing and implementing this in 0.5...

Cheers,
Chris



On 11/11/09 11:21 AM, "Jukka Zitting" <jukka.zitting@...> wrote:

Hi,

At first I used static methods in the Tika facade class, but then I
switched to normal instance methods to make it easier to use custom
Tika configuration. However, now I'm thinking that the original design
was probably better.

Any opinions on this? Essentially, which one of the following do you
like better:

    a) new Tika().parse(...);

    b) Tika.parse(...);

The benefit of a) over b) is that you can say: new
Tika(config).parse(...), but most of the people who need custom
configuration will probably in any case be going beyond the Tika
facade.

BR,

Jukka Zitting


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@...
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

[Jukka Zitting]

Hi,

Hmm, of course we could do both options, i.e. have both static and
non-static versions of the Tika methods. The static versions would
simply call the equivalent instance methods on a singleton instance
created from the default configuration.

On Wed, Nov 11, 2009 at 11:50 PM, Michael Wechner
<michael.wechner@...> wrote:
> I assume you are refering to Tika 0.5
>
> http://lucene.apache.org/tika/apidocs/org/apache/tika/Tika.html

Correct. I wanted to get the API right before we make the release.

>> The benefit of a) over b) is that you can say: new
>> Tika(config).parse(...), but most of the people who need custom
>> configuration will probably in any case be going beyond the Tika
>> facade.
>
> you mean using TikaConfig.getParser().parse(...)

Yes. And things like: new AutoDetectParser(new TikaConfig(...)).parse(...)

BR,

Jukka Zitting

[Mattmann, Chris A (388J)]

Hey Jukka,

+1 to this like I said in my other email ;)

Cheers,
Chris


On 11/11/09 3:53 PM, "Jukka Zitting" <jukka.zitting@...> wrote:


Hmm, of course we could do both options, i.e. have both static and
non-static versions of the Tika methods. The static versions would
simply call the equivalent instance methods on a singleton instance
created from the default configuration.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@...
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

[Jérôme Charron]

Hi Jukka,

+1 for :
a) for common usage
b) for advanced usage.

Best regards

Jérôme

On Wed, Nov 11, 2009 at 23:58, Mattmann, Chris A (388J) <
chris.a.mattmann@...> wrote:

> Hey Jukka,
>
> +1 to this like I said in my other email ;)
>
> Cheers,
> Chris
>
>
> On 11/11/09 3:53 PM, "Jukka Zitting" <jukka.zitting@...> wrote:
>
>
> Hmm, of course we could do both options, i.e. have both static and
> non-static versions of the Tika methods. The static versions would
> simply call the equivalent instance methods on a singleton instance
> created from the default configuration.
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: Chris.Mattmann@...
> WWW:   http://sunset.usc.edu/~mattmann/<http://sunset.usc.edu/%7Emattmann/>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
>

--
Jérôme Charron
Directeur Technique @ WebPulse
Tel: [phone] <= ** NEW **
eMail : jerome.charron@...
http://www.webpulse.fr/
http://www.shopreflex.com/
http://www.staragora.com/

[Jukka Zitting]

Hi,

On Thu, Nov 12, 2009 at 12:58 AM, Mattmann, Chris A (388J)
<chris.a.mattmann@...> wrote:
> +1 to this like I said in my other email ;)

Yeah, looks like for some reason your mail was delayed for a few hours
before it reached my gmail inbox, so I didn't see it before suggesting
the combined approach. We obviously think alike. :-)

BR,

Jukka Zitting

[Jukka Zitting]

Hi,

On Wed, Nov 11, 2009 at 11:59 PM, Mattmann, Chris A (388J)
<chris.a.mattmann@...> wrote:
> My +1 for option A and B, I think it's better in the long run since configuration is an issue.
> All methods from option B should load default static configuration. I'd be happy to take
> the lead on JIRA'ing and implementing this in 0.5...

I thought about this a bit more and realized that Java won't allow
both static and non-static versions of the same method signature in a
single class. :-( I guess we'll need to stick with either option A or
option B.

BR,

Jukka Zitting

[Mattmann, Chris A (388J)]

Hey Jukka,

What about slightly different names for the static version? Something like:

//non-static

public String detect(){//...}

//static

public static String doDetect(){//...}

It would be nice to support A and B. An alternative would be to make a StaticTika class which extends Tika, and provides static versions of the methods. Is this possible?

Cheers,
Chris



On 11/13/09 2:17 PM, "Jukka Zitting" <jukka.zitting@...> wrote:

Hi,

On Wed, Nov 11, 2009 at 11:59 PM, Mattmann, Chris A (388J)
<chris.a.mattmann@...> wrote:
> My +1 for option A and B, I think it's better in the long run since configuration is an issue.
> All methods from option B should load default static configuration. I'd be happy to take
> the lead on JIRA'ing and implementing this in 0.5...

I thought about this a bit more and realized that Java won't allow
both static and non-static versions of the same method signature in a
single class. :-( I guess we'll need to stick with either option A or
option B.

BR,

Jukka Zitting


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@...
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++