Re: [Jmap] [JMAP] CalendarEvent/parse proposition for the JMAP Calendar draft

René CORDIER <> Wed, 10 May 2023 07:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7DDBFC15154F for <>; Wed, 10 May 2023 00:17:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.693
X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=neutral reason="invalid (public key: not available)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eKwQI9MYd7Mr for <>; Wed, 10 May 2023 00:17:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 12AE9C14CE39 for <>; Wed, 10 May 2023 00:17:00 -0700 (PDT)
Received: from ?Open?PaaS?SMTP?server?for?Linagora? (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 572A03EE1D for <>; Wed, 10 May 2023 09:16:59 +0200 (CEST)
DKIM-Signature: a=rsa-sha256; b=haZyc5xvR2+LQVd2L2xILi7I/znBaI75XS/qPYrTaJP9C3eik7CDnxXviYmgNKfB+RMtgtQtPYyc/QYlWHnhE+L7q8C+/b77wVutBChvNz1KO+fQsR8eKhCSbNRqROtyCKXwJwK8svgMFd29hp5IS+QwPIYsp0GqwyHIjaDWWMv+yBrrBNXrrpb5n8wQX1YtaX/aLIz5hN1mZIxIMJbNM3tpY/yYQC0SRct5AGJ4fuCjX1SUVynORxbkk/hV0nm51e0gccDnMQRNvuiiu8SHSMqcW9v5dtcFJUsUbdbcPbwsQ9Lw88PfMZuTRD66y0BB6oqmmfh/AsVNQUUYQJ5a5w==; s=smtpoutjames;; v=1; bh=qgw4BJ9HPiLAvZcTShz3dRU7ah5CiCKLPYlYItDSFCk=; h=from : reply-to : subject : date : to : cc : resent-date : resent-from : resent-sender : resent-to : resent-cc : in-reply-to : references : list-id : list-help : list-unsubscribe : list-subscribe : list-post : list-owner : list-archive;
MIME-Version: 1.0
X-LINAGORA-Copy-Delivery-Done: 1
From: René CORDIER <>
Date: Wed, 10 May 2023 07:16:57 +0000
Message-ID: <>
User-Agent: Team-Mail/0.7.9 Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/ Safari/537.36
Content-Type: multipart/alternative; boundary="-=Part.a7.507976aa57f97dc0.18804853033.c05fb44dcb40990=-"
Archived-At: <>
Subject: Re: [Jmap] [JMAP] CalendarEvent/parse proposition for the JMAP Calendar draft
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: JSON Message Access Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 May 2023 07:17:06 -0000

Hi guys,

I should have sent that mail earlier, I'm sorry. This is the updated version of the CalendarEvent/parse proposal:

I think I did address Robert's comments in general (if I forgot something don't hesitate to point it out please).

Neil I still think the method should return CalendarEvent objects. Because as the name of the method indicates, I would expect a CalendarEvent as a result, and not just any JsCalendar object. And it is the same behavior as Email/parse, we return an email, but as it is not stored, metadata like the id are null if requested.

Let me know what you think, and if it is enough to fire a PR on the github repo!



On Apr 17, 2023 10:37 AM, from René Cordier Hi Neil,

Thanks for the feedback! I will take it into account as well alongside Robert's comments and propose an updated version of this document when i have a bit of bandwidth. Then we can see how to integrate that to the Calendar draft :)



On Apr 14, 2023 11:01 AM, from Neil Jenkins This is definitely a useful method. I think the result type should be pure JSCalendar rather than a JMAP CalendarEvent, because it's not saved in the store anywhere so doesn't have an id etc.

Regarding an iCalendar file with multiple events (with different UIDs), I'm happy with either returning an array of JSCalendar event objects or a single JSCalendar group object. I think I agree with Robert that the former is probably slightly better though, just because otherwise it's easy to only implement something that handles an event response and then get surprised when someone passes in a multi-event file, whereas if it's always an array you know you need to handle the possibility of multiple.


Jmap mailing list