WIP: Initial refactoring process

[SrMouraSilva]

Hello, @falkTX, I am creating this pull requests to make the initial step on refactoring the backend of this great project.
You can read more about my idea on
https://forum.mod.audio/t/mod-oss-will-you-help-to-improve-it/10196/24?u=srmourasilva

This pull request probably moves more things that expected and also uses Python 3.10 (I am not sure which version I should use). And, as you can see, I am not included any unit test yet.

I am open to starting a dialog about this initiative and I am open to remake this work on small pull requests.

Let I know what you think about it.

Current changes

• initial packages structure definition
• move handlers to new package
• move file_receivers to new package
• move almost all snapshot controllers to new package
• add SnapshotService

[falkTX]

we sadly need to keep compatibility with python3.4, because that is the version used in MOD OS and we have no time to do proper testing and verification of a big python update at this point.
so while moving things around, they need to stay as is unless it is clearly evident a bug-fix.

IMO moving files should really keep everything as-is, so that it still works exactly the same way as before.
then after reorganizing things we are more free to do changes, but very careful as to not break backwards compat.

I like the approach to reorganize the API calls, but each one should have the accompanied javascript related change on the same commit, and come after a split/reorganization of the files, never on the same PR/commit as a file split.

[SrMouraSilva]

Thank you about your quickly response.

Next week, I will create a new pull request with Python 3.4 compatibility.

Following your recommendation, my idea is to split the handlers and Snapshot endpoints to new files, similar to this PR, but without codes changes. I think that this way, with a pull request small scope, will be easier for we validate the contribution flow.

I would like to maintain TODOs and code documentation to make easier the futures refactoring. What do you think about it?

I also will reflect about how to include unit tests to avoid behavior changes. It is quite tricky because one of the reasons of the code refactoring is to help the tests creation 😅.

I like the approach to reorganize the API calls, but each one should have the accompanied javascript related change on the same commit, and come after a split/reorganization of the files, never on the same PR/commit as a file split.

I agree with you.