> >> I haven't looked yet at the way extension points work, so I don't really >> have an idea on how difficult this would be. Some of Tika's classes (mostly >> MimeType) are used explicitly in several places of the core, would we need >> to hide them behind non Tika objects in order not to have direct >> dependencies? >> > > Yes, that was my idea.
My concern with this approach is that we end up having something artificially complex and add all sorts of intermediate objects on the mimetype side just to avoid a limitation of Tika which might be sorted later anyway. > I suppose we could try to make progress on the Tika plugin as it is now >> (i.e. with the work around I described earlier) and refactor things in a >> later stage using the extension points. Makes sense? >> > > We could, but if we can figure out a cleaner solution now, then we should > follow it instead of committing that workaround and then having to refactor > it ... Sure, but it also mean that we would hopefully get a working version of the Tika parser quicker by not making it depend on the extension point refactoring. It could also be argued that the Tika parsing and the refactoring of the extension points are two separated issues which could be possibly covered by different people. Moreover the workaround is just a reference to a class in one file, replacing this during the refactoring would hardly add any work. J. -- DigitalPebble Ltd http://www.digitalpebble.com
