search

OCR-D / ocrd-webapi-implementation

4 stars 0 forks source link

Running processors #1

Closed kba closed 2 years ago

kba commented 2 years ago

https://github.com/joschrew/ocrd-webapi-test/blob/0494daafd0cca717cf82438850ad01924f7d46f4/ocrd-webapi-test/main.py#L148

I think it would be best if we had this in OCR-D/core. I am not familiar with FastAPI but I asume there is a way to compartmentalize endpoints and plug them into the FastAPI main loop. In core, we'd define a function like wrap_processor_fastapi(executable) which sets up the processor endpoints, delegates parameter validation etc. to core internals and returns an endpoint for that particular processor. This could then be plugged into your main app,

joschrew commented 2 years ago

Ok, I looked into the code you showed me yesterday and tried to understand what you meant. Here is how I understand it now: With wrap_processor_fastapi(executable) a function (endpoint) is created for a particular processor. For every processor which should be available with the API this function will be called. At startup for example. The resulting function should then be made available at for example /processor/ocrd-dummy. For every registered processor his own endpoint will then be available. ???

kba commented 2 years ago

Ok, I looked into the code you showed me yesterday and tried to understand what you meant. Here is how I understand it now: With wrap_processor_fastapi(executable) a function (endpoint) is created for a particular processor. For every processor which should be available with the API this function will be called. At startup for example. The resulting function should then be made available at for example /processor/ocrd-dummy. For every registered processor his own endpoint will then be available. ???

:+1:

joschrew commented 2 years ago

I closed this issue because I removed the processor part for now and because this is addressed in https://github.com/OCR-D/core/pull/884 as far as I understand it