Inconsistency in bindings location and modules content. Wiki/Issue tracker handling.

[tarelda]

• Gitea version (or commit ref): master
• Git version: Not relevant
• Operating system: Not relevant
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist: Not relevant

Description

First some background. Recently, I had to migrate my old gitlab instance to something newer and chose gitea instead of newer gitlabs (honestly I just want my 16GB of RAM back). I used python to write migration script that was even able to extract and compact snippets. Unfortunately something I couldn't get around was handling wikis. I need them to be imported too, but there is no API endpoints for it (tried method with directly making requests to ui but was too inconsistent in behaviour). Then I stumbled upon #488 and mad me realize that the best way to do it is just patch API and my journey begun...

Thoughts concerning code

After a few hours spend walking through code I noticed two things that bothered me:

1. Bindings are located as well as in built-in auth module as in separate api module (I can't justify why it is separated).
2. Auth module contains quite a lot of forms that are not related to authorization.

My solutions:
Alternative 1. Move out of auth and api module all of the bindings into separate package named bindings.
Alternative 2. Essentially alternative 1, but auth related bindings and forms keep in the module.
Alternative 3. Create package forms and move all of the non-auth related forms there. Refactor API routers to use built-in api module which has bindings and handlers embedded.

Wiki/Issue tracker API situation

First of all, my main issue was with the fact that I needed to create page to have local wiki initialised. My proposition is that local wiki repo should be initialized when feature is enabled and deleted if disabled?
Secondly, where exactly handle Wiki/Issue tracker? My first idea was to just add PATCH request for /repos/{user|org}/{repo}, which is more compatible with github API.
But I find more appealing and CRUD friendly, creating two new endpoints /repos/{user|org}/{repo}/wiki , /repos/{user|org}/{repo}/issuetracker with appropriate set of handlers for methods GET and PATCH.
GET method would be used to determine which type of unit is enabled and PATCH to switch inbetween them.

Bottomline

I don't want waste my time working a code that won't be accepted by maintainers or community. So tell me what are your thoughts?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.