tika-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: Questions
Date Mon, 02 Jul 2007 11:38:21 GMT
Hi,

On 7/2/07, Carsten Ziegeler <cziegeler@apache.org> wrote:
> Bertrand Delacretaz wrote:
> > I've mentioned Tika to a few colleagues lately, and one thing that
> > comes up often is that there are many document/format parsing
> > libraries around, which should ideally be usable as Tika plugins with
> > as little changes as possible.
> >
> > But these libraries' dependencies are all around the place, and
> > probably conflicting in many cases.
> >
> > It might be good to take that into account in the design of Tika, and
> > use solid classloading and isolation mechanisms. OSGI comes to mind,
> > assuming it doesn't bloat the whole thing.
> >
> Yes, in many cases a solid classloading mechanism is a must and OSGi
> definitly implements this properly.
> I think, we can leave this open (= do not need to require OSGi) if we
> have an open way of registering the plugins. Registering in an OSGi
> environment might then be slightly different compared to registering in
> a non OSGi environmnent. Of course, using the latter one might result in
> classloading problems :) But then it's up to the developer to decide in
> which environment tika should run with all the pros and cons that come
> with this decision.

+1 I think that the core Tika framework should be very lightweigth and
easily composable in various different environments. I even think that
we shouldn't mandate any "official" configuration or composition
mechanism. We may have some simple implementation as the default, but
it should be possible to use things like Spring or OSGi or whatever to
manage more complex scenarios.

BR,

Jukka Zitting

Mime
View raw message