Repository navigation
Read calendars through the IETF JMAP URN, with the vendor one as fallback; release 0.4.3 - #86
Merged
Merged
Conversation
…back The server now answers its calendar methods under urn:ietf:params:jmap:calendars in the draft's shape, and plMail's vendor URN is to go once the apps read the IETF one (pl_mail#409). The app now declares the IETF URN whenever the session advertises it, and its calendar model is spelled in the draft's names: calendarIds, one recurrenceRule, baseEventId. A server released before the IETF URN advertises only the vendor one, so that is still read: CalendarDialect.PLMAIL translates plMail's earlier shape (calendarId, recurrenceRules, seriesId) into the draft's at the edge, and back on a write. Retiring the vendor URN is deleting that enum entry and Capability.PLMAIL_CALENDARS. The draft has no isRecurring, so under the IETF URN recurring is read from the rule, and a create's from the rule that was sent. Under it a get is held to core's maxObjectsInGet, which is what the server allows there. Also corrects ContactAutocomplete's comment saying the server has no Contact/get: it serves RFC 9610 contacts now. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FXqu9YFt9pfgWBaXXy2zZa
…ertion Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FXqu9YFt9pfgWBaXXy2zZa
…TF URN The server now publishes isRecurring under the IETF calendars URN as the vendor property plmail.org:isRecurring, on CalendarEvent/get and on a create's answer. The model reads that name, the vendor dialect reads plMail's plain isRecurring into it, and it is asked for wherever the rule is. So an imported event whose rule the server could not convert reads as not recurring again under either URN; only a server that publishes neither still leaves the rule as the answer. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FXqu9YFt9pfgWBaXXy2zZa
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FXqu9YFt9pfgWBaXXy2zZa
karatektus
added
the
chore
Claude
github-actions
Bot
added
area: mail
…nd the IETF one's on its own Three repository tests asserted a hundred events a page and the server's +2 years horizon, which only the vendor calendars URN publishes; under the IETF URN a get takes core's maxObjectsInGet and no horizon is published. They now run against a vendor-only server, and a fourth pins one page of 120 under the IETF URN. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FXqu9YFt9pfgWBaXXy2zZa
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Counterpart to karatektus/pl_mail#409 (step 1, the Android half). That issue stays open on the server side; this is labelled
chore, as it is there.What changes
urn:ietf:params:jmap:calendarswhenever the session advertises it, and the calendar model is spelled in the draft's names (calendarIds, onerecurrenceRule,baseEventId).urn:plmail:params:jmap:calendars(every plMail before the IETF URN) is still read.CalendarDialect.PLMAILtranslates plMail's earlier shape at the edge, so retiring the vendor URN later is deleting that enum entry andCapability.PLMAIL_CALENDARS.plmail.org:isRecurring(orisRecurringunder the vendor URN), not from the rule: a rule the server could not convert expands to one occurrence.maxObjectsInGet, which is what the server allows there.ContactAutocomplete's comment no longer says the server has noContact/get.VERSION_NAMEand the Play release notes.Needs no newer server: an older one gets the vendor URN. The IETF URN and
plmail.org:isRecurringcome with karatektus/pl_mail#411, merged into the server'smilestone/v0.4.1.How it was checked
./gradlew :core:jmap:test(74 calendar tests, including the newCalendarDialectTest) andspotlessCheck, locally.:core:datawas not run locally, for lack of an Android SDK; its fake server now speaks either URN and refuses the wrong one, with two new tests against a vendor-only server. CI on this pull request runs the whole build. Not run on a device.Checklist
Generated by Claude Code