[
https://issues.apache.org/jira/browse/TIKA-4554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Allison updated TIKA-4554:
------------------------------
Description:
In 3.x, we had four different ways to fork a process to handle dangerous files
(and what file is not dangerous?):
a) tika-batch
b) tika-server
c) tika-pipes
d) fork parser
For 4.x, we should centralize/unify our forking through tika-pipes if possible.
We've already removed tika-batch on TIKA-4333. We removed the full server
forking as part of the enormous refactoring on TIKA-4545.
Let's remove the ForkParser from 4.x. I propose that if anyone needs it, we can
write a light wrapper around tika-pipes that would take an InputStream, write
it to a temp file and then run tika-pipes against the file.
Any objections?
was:
In 3.x, we had four different ways to fork a process to handle dangerous files:
a) tika-batch
b) tika-server
c) tika-pipes
d) fork parser
For 4.x, we should centralize/unify our forking through tika-pipes if possible.
We've already removed tika-batch on TIKA-4333. We removed the full server
forking as part of the enormous refactoring on TIKA-4545.
Let's remove the ForkParser from 4.x. I propose that if anyone needs it, we can
write a light wrapper around tika-pipes that would take an InputStream, write
it to a temp file and then run tika-pipes against the file.
Any objections?
> Remove the ForkParser in 4.x
> ----------------------------
>
> Key: TIKA-4554
> URL: https://issues.apache.org/jira/browse/TIKA-4554
> Project: Tika
> Issue Type: Task
> Reporter: Tim Allison
> Priority: Major
>
> In 3.x, we had four different ways to fork a process to handle dangerous
> files (and what file is not dangerous?):
> a) tika-batch
> b) tika-server
> c) tika-pipes
> d) fork parser
>
> For 4.x, we should centralize/unify our forking through tika-pipes if
> possible.
> We've already removed tika-batch on TIKA-4333. We removed the full server
> forking as part of the enormous refactoring on TIKA-4545.
> Let's remove the ForkParser from 4.x. I propose that if anyone needs it, we
> can write a light wrapper around tika-pipes that would take an InputStream,
> write it to a temp file and then run tika-pipes against the file.
>
> Any objections?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
