Re: [Jmap] Tasks (draft-ietf-jmap-tasks-04) and recurrence

Hans-Joerg Happel <happel@audriga.com> Wed, 15 June 2022 17:25 UTC

Return-Path: <happel@audriga.com>
X-Original-To: jmap@ietfa.amsl.com
Delivered-To: jmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D99C6C14F742 for <jmap@ietfa.amsl.com>; Wed, 15 Jun 2022 10:25:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.784
X-Spam-Level:
X-Spam-Status: No, score=-3.784 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.876, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwwYvkPgI4Nf for <jmap@ietfa.amsl.com>; Wed, 15 Jun 2022 10:25:20 -0700 (PDT)
Received: from mail.audriga.com (mail.audriga.com [176.221.42.35]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A850C14F730 for <jmap@ietf.org>; Wed, 15 Jun 2022 10:25:19 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.audriga.com (Postfix) with ESMTP id A6CE2A27F for <jmap@ietf.org>; Wed, 15 Jun 2022 19:25:16 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mail.audriga.com
Received: from mail.audriga.com ([127.0.0.1]) by localhost (mail.audriga.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvmUqYJu_0Fl for <jmap@ietf.org>; Wed, 15 Jun 2022 19:25:14 +0200 (CEST)
Received: from [192.168.10.147] (ip-109-090-161-242.um36.pools.vodafone-ip.de [109.90.161.242]) (Authenticated sender: happel@audriga.com) by mail.audriga.com (Postfix) with ESMTPSA id 0A570A0D2 for <jmap@ietf.org>; Wed, 15 Jun 2022 19:25:14 +0200 (CEST)
Content-Type: multipart/alternative; boundary="------------Dt9jsuUpxHhpaRgUgYFKSL4Q"
Message-ID: <e532faf2-8f29-39c3-85de-6e08a3496f96@audriga.com>
Date: Wed, 15 Jun 2022 19:25:13 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1
Content-Language: en-US
To: jmap@ietf.org
References: <cf696f96-bd96-4a23-b375-a4b52ea47685@www.fastmail.com> <f4cdbd28-6928-470f-a247-044701848ffe@dogfood.fastmail.com>
From: Hans-Joerg Happel <happel@audriga.com>
In-Reply-To: <f4cdbd28-6928-470f-a247-044701848ffe@dogfood.fastmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/Ab6b0QSNhKizs6vFGYJsZstPwdU>
Subject: Re: [Jmap] Tasks (draft-ietf-jmap-tasks-04) and recurrence
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: JSON Message Access Protocol <jmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jmap>, <mailto:jmap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jmap/>
List-Post: <mailto:jmap@ietf.org>
List-Help: <mailto:jmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jmap>, <mailto:jmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jun 2022 17:25:23 -0000

Hi Ricardo,

thanks for taking your time to review and raising concerns!

I think Neil already made many good points here.

I can probably add, that from a practical point-of-view, my experience 
is, that few users do use recurring tasks, even if supported by the 
underlying system. One might assume that such users will make sure to 
use a sufficiently powerful "client B" by their own choice.

Regarding Neil's their proposal, I'd probably argue that this is too 
abstract to foresee for users at setup time (i.e., many users will never 
use recurring tasks, even if their server allows to. In that sense, 
(server-side?) expansion might be the "cleanest" issue. I need to check 
deeper however if this would be easily feasible in the current state.

Another option might be to add a boolean like "hasRecurrence" to each 
affected "main" task, so that clients are taught that this certain task 
might not be rendered correctly (perhaps a little ugly for the client 
implementation/user interaction though)

Thanks and best,
Hans-Joerg

On 14.06.22 08:23, Neil Jenkins wrote:
> The state strings are primarily for the server to advertise support. 
> If the server supports recurrences, either:
>
>   * the client supports recurrences: fine.
>   * the client doesn't support recurrence expansion but can opt in to
>     the capability and ask the server to expand: fine.
>   * the client doesn't support recurrences in any way – it can see the
>     capability is there on the server and either refuse to add the
>     account with an appropriate error, or warn the user about
>     compatibility issues.
>
> There are many todo systems that don't support recurring todos, so I 
> think it's a reasonable thing to split out as a capability. You 
> definitely want to avoid splitting it up into different capabilities 
> as much as possible to avoid exponential combinations to test and 
> support, but I think this one is reasonable.
>
> Cheers,
> Neil.
>
> _______________________________________________
> Jmap mailing list
> Jmap@ietf.org
> https://www.ietf.org/mailman/listinfo/jmap