shamoon
shamoon
> i'm not familar with the design of the software. this was the one approach which i thought that it could work because it uses the "plugin/registration" system without modifying...
> I think you got this in a wrong way. I'm not against changing the implementation. Feel free to tell me how it would be better. I will try to...
Yea, without having looked at the actual implementation this does seem more in the right direction. I would: 1. Get rid of the zip parser completely, it's just a vestige...
> pdf cannot be used anymore since it‘s now a supported type. Indeed, so the test should still test an _unsupported_ type. > i think removing the pdf parser would...
> * it's now more hardcoded and hacky. > * shouldn't we introduce another type of hander, e.g. adding a get_archive_handler() function into the zip_consumer_declaration which can be overloaded in...
Oh boy, kind of a brain fart there. I'll mark as draft. It occurs to me maybe we could automagically convert these things into the settings object??
Yea. Hmm, like could we parse settings (as is) and then parse app config and override those? I guess that doesn't really make sense, you lose the runtime ability to...
I think Im being silly. The `OcrConfig`, `GeneralConfig` stuff is good, I'll do it like that
Ok, this should actually do what it's supposed to now =)
Yea, and without sounding rude, it strikes me as a bit of an odd contribution, like perhaps something better left to core maintainers of a project?