WebDav Storage backend #1162
No reviewers
Labels
No labels
2018.09
2019.01
2019.03
2019.06
2019.09
2019.12
2020.03
2020.06
2020.09
2020.12
2021.03
2021.07
2021.09
2022.02
2022.06
2022.09
2022.12
2023.04
2023.05
2023.09
2024.03
2024.06
2024.09
2024.12
dependencies
Hackathon 2021
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: friendica/friendica-addons#1162
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/webdav_storage"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This a first cut for a WebDav Storage backend.
But I do need some additional business logic for creating DAV-collections for embedding files in them (I don't know webdav enough yet ;-) )
Needs https://github.com/friendica/friendica/pull/10637 and https://github.com/friendica/friendica/pull/10825 first
Functionality:
ToDos:
Would it be possible to eventually extend this to be selectable via a user as well? So that individual users could select their own WebDAV storage?
The backend adapter would be the same, I guess we have to adapt the way how we save data per user. Since we already save the class-name in each table entry, I would say yes but with some additional logic at some core classes :)
Uuuuh, I feel like I have to put my foot down here, having per-user backend configuration would not only bring extreme complexity in an already sensitive area, but it would impact performance as well as users would connect with variously-powered WebDAV backends.
My opinion is that if a Friendica user knows about WebDAV and has their own server, they also can and probably should run their own Friendica node as well.
I think if we would provide some cloud storage feature it would make sense to let users add their own external storage (WebDAV, S3, ...) But we don't have such a feature and it would be out of the scope of Friendica. So, I think it's sufficient to have additional storage backends on node level (admin only).
The Filesystem backend allows for cloud storage but I still think it's a mistake to allow individual users to set their own backend. It would create new and interesting issues that these users wouldn't be able to troubleshoot themselves without involving their node admin.
OK, I tried it locally and the unit tests ran fine .. It should work, but I'm a little bit unsure gg .. I will add another dev-instance and try it for some time with full logs :D ..
Edit: I don't currently know what's happening to the test :D
It's still working .. not errors so far, every picture appears at the timeline and private posting works as well :X ...
I deleted a picture as well and the files including preview and the empty folder got deleted as well ..
I believe I will set it "ready for review" after adding the feedback of @MrPetovan ...
@annando / @MrPetovan / @tobiasd - any suggestions for tests?
What I did:
I have no real usable idea for how to test it under stress situations for the server. I think that would be interesting, how the performance compares for "big" nodes.
Concerning this "individual credentials" thing: I have the idea of combining Nextcloud with Friendica. This means that one could then login to Nextcloud via Friendica (or vice versa?). Pictures would be uploaded to the personal Nextcloud storage and could then be accessed by Friendica via WebDAV.
Latest branch is working as well including the new Config class
--> here we go :-) Ready for Review
Don't forget https://github.com/friendica/friendica/pull/10825 beforehand
I've reviewed this PR and requested several changes, I'm waiting for your input.