Support for Self-Hosted Services and Resolution of WebDAV CORS Issues via Compile-Time Configuration

[jiongxuan]

Problem Statement

I need to support self-hosted services for my project, and I'm encountering issues with WebDAV causing CORS (Cross-Origin Resource Sharing) problems during synchronization. The current approach requires familiarity with Kotlin syntax and involves multiple changes across the codebase. This makes the process complex and time-consuming.

:grey_question: Possible Solution

A short-term solution would be to modify the configuration at compile time, allowing for self-hosted services and resolving CORS issues.

This will be done by splitting the configuration logic into a separate build file, making it easier to manage and more straightforward to implement. I will complete this change soon and submit a PR.

In the future, I will explore the possibility of switching the configuration at runtime, which will require more time to design, especially considering data migration concerns.

:arrow_heading_up: Describe alternatives you've considered

This issue is similar to Issue #4 and #16 , but for now, I don't need to integrate it into the local build. Keeping the update process timely is more important. The main goal is to support switching to a self-hosted domain and resolving the WebDAV CORS issue.

:heavy_plus_sign: Additional context

This change will ensure the ability to switch to a self-hosted environment and address WebDAV CORS issues without requiring immediate runtime changes. The proposed approach is focused on a compile-time solution to ensure flexibility and ease of implementation.

[jiongxuan]

@johannesjo Thank you so much for the kind words! It was my pleasure to contribute.

Right now, I’m evaluating two potential solutions. One is to modify the URL at runtime, but it feels like more of a temporary fix since it doesn’t fully address the CORS issue, especially in cases where domain names and self-hosted environments don’t match.

The other solution, which I find more promising, is moving towards a fully offline solution for Android, and possibly iOS as well. This could be done using Cordova. I did a quick setup this afternoon, and while it’s definitely feasible, there are some details that need to be worked out.

I’ve noticed in a few other issues that people have suggested similar ideas, and I think it’s worth exploring further. I’d love to hear your thoughts on this approach. Do you have any advice or things I should keep in mind?

As for migrating existing users, it might be useful to assess how many current Android users there are. If you have any data on that, it could help with the evaluation. I’ve also been considering a dual approach: keeping things the same for existing users while applying the new offline solution for new installations (or for users who uninstall and reinstall). That way, we can balance both approaches.

Looking forward to your thoughts!

[johannesjo]

Yes, using Cordova (or capacitor which is a bit more modern) is probably a good solution.

The biggest issue for me -apart from the migration -is the build pipeline (I want to have the least amount of ongoing work required for each build as possible). But this also should be easier when using capacitor.

I like your suggestions how to tackle the migration process. Just continuing to use the old approach for users who already use the app, could work and avoid the hassle of migration and communicating it to the user.

There are around 4000 (active??) Android users.

[jiongxuan]

Thanks for the feedback! I agree that Capacitor seems like the more modern choice, and after trying it myself, I found the deployment process to be much simpler than Cordova. It’s definitely an advantage in terms of reducing the build pipeline complexity. Another benefit is that Capacitor has better support for web and mobile hybrid apps, so it could offer more flexibility down the road.

I’m glad you’re on board with the migration plan. It should make things smoother for current users while giving us room to explore the new solution without too much disruption. With around 4000 users, this gradual approach seems like the least risky option.

Things have been pretty busy at work lately, but I’ll keep an eye on this and continue working on it when I have time. When I make more progress, I’d love to discuss the potential solutions further and refine the direction we’re taking.

Looking forward to refining it further!😄

[johannesjo]

That's great! I am looking forward to make progress on this. Please let me know if I can be of any assistance! We can also arrange some google meet call to talk directly, if you like. Just write me an email to contact@super-productivity.com.

[jiongxuan]

Thanks for the offer! I’m open to whatever helps the project move forward.

I’ll try to carve out some time to explore the solution further, and when I make progress, I’ll open a separate feature issue to detail everything.

By the way, since this issue was mainly about addressing the self-hosting challenges, which we’ve now resolved, I think it’s safe to close it for now. This will help keep the project’s issue tracker more organized. 😄

(Due to network restrictions in China, I am unable to use Google Meet smoothly for the time being, so I recommend communicating via text first. If necessary, I will find a way to prepare. Thanks for understanding!)

[johannesjo]

Ahhh. Ok no problem! We'll sure find something else (maybe Jitsi) :)

I am closing this then. Thank you very much once more!