You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As you can see, fetcher names may be arbitrary names that refer to configuration sections, and there may be multiple fetchers of the same type configured as well (for example, with different HTTP timeout values).
So, the artificial limitation of fetcher names added in 304f855 does not make sense. My suggestion is to remove it.
The text was updated successfully, but these errors were encountered:
You are right. My approach is to always restrict argument values to avoid unexpected results, but here didn't understood the Tika feature. I tagged the 1.3.1 version with the PR merged.
#33 added a way to set fetcher names for Tika 2.0. Fetcher names refer to configuration on the Tika server side where different implementations can retrieve the files to be processed via HTTP, from S3 and so on. Documentation is at https://cwiki.apache.org/confluence/display/TIKA/tika-pipes#tikapipes-Fetchers.
An example of how fetchers can be used when making requests is given in another section of the documentation, at https://cwiki.apache.org/confluence/display/TIKA/tika-pipes#tikapipes-FetchersInClassicServerEndpointsFetchersintheclassictika-serverendpoints.
As you can see, fetcher names may be arbitrary names that refer to configuration sections, and there may be multiple fetchers of the same type configured as well (for example, with different HTTP timeout values).
So, the artificial limitation of fetcher names added in 304f855 does not make sense. My suggestion is to remove it.
The text was updated successfully, but these errors were encountered: