Support managed attachments (RFC 8607)
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Tranquilla
- Stack tecnologico
- python
- Ambito
- api, backend-api-design
Direzione di ricerca
Start with section 3.1 of docs/design/FEATURE_COMPLETE_ROADMAP.md and RFC 8607, then inspect tests/test_caldav_unit.py for the existing inline ATTACH fixture. First decide whether managed attachments are worth supporting and what the API should accept and return; if proceeding, done means implementing the listed detection, operations, object methods, limits and compatibility hints, with tests that can skip on unsupported servers.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
The task is to do research on RFC 8607, assess if it's relevant for the caldav library, and (if it's deemed worth it) implement support. Claude has already done some research, see the findings below.
⚠️ This issue is AI-generated (Claude Opus 5 via Claude Code) on behalf of tobixen, from the prompt: "3.1 managed attachments needs an issue"
Tracking issue for section 3.1 of docs/design/FEATURE_COMPLETE_ROADMAP.md, which had no issue behind it.
There is no attachment support in the library today — no hits for ATTACH, MANAGED-ID or attachment anywhere in caldav/.
Scope: managed attachments, not attachments in general
Worth separating two things that both go by "attachment":
- Inline / URI
ATTACH(RFC 5545) — a plain iCalendar property, either a URI or base64 binary. This already works, in the sense that the library treats it as opaque iCalendar data and hands it toicalendar;tests/test_caldav_unit.pyeven has a large base64ATTACHfixture. Nothing to implement, though convenience accessors could be argued for. - Managed attachments (RFC 8607) — the attachment is stored server-side, outside the calendar object. The client POSTs the file to a separate URL, the server answers with an
ATTACHproperty carrying aMANAGED-ID, and add/update/remove are HTTP POSTs with?action=attachment-add|attachment-update|attachment-remove. This is what is missing, and it is what this issue is about.
Tasks
- Detect server support — the
CALDAV:managed-attachments-server-URLproperty, and thecalendar-managed-attachmentstoken in theDAV:header -
attachment-add,attachment-update,attachment-removePOST operations - Handle
MANAGED-ID, and theFMTTYPE/FILENAME/SIZEparameters -
event.add_attachment()/event.remove_attachment()on the object API - Respect the server's
max-attachment-sizeandmax-attachments-per-resourcelimits, and give a decent error when they are exceeded - Compatibility hints, so the tests skip rather than fail
- Decide what the API takes and returns — a path, a file object, or bytes; and whether a download streams or buffers
Why this may not be worth doing soon
The roadmap already rates it low priority, and I think that is right:
- Server support is thin. Apple Calendar Server implements it; most of the servers in the docker test matrix do not, so most of the work would be untestable.
- It drags file handling into a library that currently only moves text around — streaming, temp files, memory limits for large blobs. That is a real API design question, not just a protocol binding.
- The people who ask for attachments usually mean inline
ATTACH, which already round-trips.
So: worth having the issue so section 3.1 is not an orphan, but not obviously worth doing before ACL, alarms or the robustness work.
RFC: https://datatracker.ietf.org/doc/html/rfc8607
⚠️ AI-generated by Claude Opus 5 via Claude Code on behalf of tobixen.
- Lingua principale
- Python
- Stelle
- 412
- Fork
- 113
- Merge medio
- 1g 14h
- PR unite (30g)
- 26
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di python-caldav/caldav
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
python-caldav/caldav#687 ·
I maintainer di solito rispondono entro 1 giorno
-
Principal.calendar_home_set and get_calendars() disagree on where calendars live without a calendar-home-setForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 52/100
python-caldav/caldav#749 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
python-caldav/caldav#725 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 48/100
python-caldav/caldav#720 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 30/100
python-caldav/caldav#704 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di python-caldav/caldav
Issue simili
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
huggingface/smolagents#2976 ·
I maintainer di solito rispondono entro 1 giorno
-
bug Triage-Needed
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
FuRongJun-1999/dsh-memory#170 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
pgvector/pgvector-python#163 ·
-
[开源推荐] 打拼音就出篆书的输入法,附古文字创作小工具Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 82/100
521xueweihan/HelloGitHub#3940 ·