nextcloud / nextcloud/nextcloudfileproviderkit
Explore limiting PROPFIND requested properties for initial enumeration (and working set changed files checking)
Nobody has claimed this yet.
- Dominant language
- Swift
- Stars
- 8
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Description
Some initial checks show that we limiting the number of requests on a PROPFIND can dramatically speed up the response time from the server:
Not scientific. But timing curl calls:
With only etag:
curl -X PROPFIND -H "Depth: 1" -H --data 0.01s user 0.01s system 0% cpu 2.941 total
With displayname, content length, and etag:
curl -X PROPFIND -H "Depth: 1" -H --data 0.01s user 0.01s system 0% cpu 6.058 total
Running PROPFIND with as few properties as possible, and then running follow-up PROPFIND requests with all needed properties on relevant items may allow for speeding up enumeration
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the issue's curl timing comparison for PROPFIND with only etag versus the additional properties, then trace initial enumeration and working-set changed-file checks. Done means a measured decision and an agreed implementation path for limiting requested properties and fetching needed properties only for relevant items.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- swift
- Domain
- desktop, performance
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100