paradizelost/paperless-ngx
1
0
Fork 0
mirror of https://github.com/paperless-ngx/paperless-ngx.git synced 2025-04-02 13:45:10 -05:00
Code Issues Packages Projects Releases Wiki Activity

Updated Backend Ideas List (markdown)

Trenton H 2023-08-01 17:54:13 -07:00
parent 00f7f790ce
commit 6f0aada6f6
1 changed files with 22 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
Backend-Ideas-List.md

@ -1,3 +1,17 @@
## Breaking Changes
### Dropping ARMv7
- No more need to custom build packages for the Docker image
- Allows updating cryptography, scipy and probably more
- Allows updating the Python version (to at least 3.10)
### Removing GPG / Encryption
- Encrypting documents unsupported since 0.9, many years ago
- Provides no benefit
- Does still linger in the code base here and there
## Context Managers
Updating the consumer and maybe the parsers to be context managers.
@ -9,13 +23,7 @@ Updating the consumer and maybe the parsers to be context managers.
- supervisord isn't meant to run as PID 1, S6 is
- s8 startup can be separated into independent units, with dependencies between them, which could slightly improve startup time
Initial work done in https://github.com/paperless-ngx/paperless-ngx/tree/feature-s6-overlay
## Dropping ARMv7
- No more need to custom build packages for the Docker image
- Allows updating cryptography, scipy and probably more
- Allows updating the Python version (to at least 3.10)
- Initial work done in https://github.com/paperless-ngx/paperless-ngx/tree/feature-s6-overlay
## Migration Squashing
@ -31,4 +39,10 @@ Replace `from .x.y import z` with `from a.b.x.y import z`. Just makes things st
- all in one library for notifications across multiple services, from email to self hosted instances
- need to standardize what is notified and how it is tagged (ie always include `paperless-ngx`, and maybe a level like `warning`, `error`, etc)
- Probably the user provides a filepath to the config
- as much as possible, would likely want to persistent the client through a consumption, to prevent extra work
- as much as possible, would likely want to persistent the client through a consumption, to prevent extra work
## External Services
- External OCR services, using an API, could provide more recent tesseract and ghostscript versions, potentially fixing issues faster than Debian updates (thinking Alpine)
- Is time consuming, so might need celery there? And a database?
- fastapi could easily set this up