IETF Logo Mail Archive

Re: [calsify] JSCalendar: what to do with JSTask?

Adrian Apthorp <adrian@apthorpia.com> Sat, 01 September 2018 07:55 UTC

Return-Path: <adrian@apthorpia.com>
X-Original-To: calsify@ietfa.amsl.com
Delivered-To: calsify@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C505130EAC for <calsify@ietfa.amsl.com>; Sat, 1 Sep 2018 00:55:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apthorpia-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7oQNGgONqto for <calsify@ietfa.amsl.com>; Sat, 1 Sep 2018 00:55:06 -0700 (PDT)
Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4349412426A for <calsify@ietf.org>; Sat, 1 Sep 2018 00:55:06 -0700 (PDT)
Received: by mail-pl1-x62a.google.com with SMTP id a4-v6so6439590plm.13 for <calsify@ietf.org>; Sat, 01 Sep 2018 00:55:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apthorpia-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=Cd1ZBEoOupL1H9odZW4fg+BYCw59iUWtBVkNhcHQQ+I=; b=MMmMSN1v68rKPk64DVxjeRhTkfIgqKu6oqFebWXaS7Ir8CgMQTKwaoyOsX/p+vHokm 9gfUKVjBUazBvUy7HqmSHy8F2S7fG0mMQ2bdttD3Z8wKSOrDaqM7tq3L1OcHTe4c0h1y 1JztdEghS1cQ3NZFaUrqnkzoBuYpgAzusih1TGEjWlILDCCpb4ZM57QEi00/2tQrwtHW E/OiSfmj2OsnSm/2/7SSRZULGr9FXaL62JfB1OOA6lX/yMMQv3kWEJHoQ2X1i2BaJjj2 hKgB/EMC3hfJ5kfVJGXHlGbkYsUEYTuFq9HPufTa3xNhxPvTrr/6pSCyg0xUjdVZkX0b LZwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Cd1ZBEoOupL1H9odZW4fg+BYCw59iUWtBVkNhcHQQ+I=; b=G/NkPhLwj+tz9C/ktBFOYQC65PnmxvlLFvT6x82es+OAMOHi7qrlYlgKOthlkjem63 K/lZCIH6byRPMc3K5t2h9+JM4I1dcNHivoGGS9zWu3eW6Di8c6qKz7r35TgANBf/z5ci Vbylxz9SNcm510CcQu14fQ8gYuXjc6OL7T822Jhw7z7oIzrwpp2PDJqnb24o8/hmzsAg r4NEXyHQO++5V/Mhey83nMr9Zl9zTcR28UW1M3cDbpuEv/pWsVMCcyEKQCcf/MRnQ9+a QlHO7h0rqYxztu4IwiQKdFqgxHkdP9petarZVPD70fiwc4Gqx2wtQlEsqFm89EkgWldG a3Bw==
X-Gm-Message-State: APzg51BDw34NpFh4WXp0a59UCi1lxjhHO64NL+LwGs+yNTXcclGWjWYA qdZYoBqmHPQdETN7Ge5GXI4cT5IdYGk=
X-Google-Smtp-Source: ANB0VdZ+0nRRSgY65p/oLRrPeZbxJb96gON5Vsw6jO+IZLtGAQ00VPSmuOv1S82kIDbpEJmIvXYPTA==
X-Received: by 2002:a17:902:2ac3:: with SMTP id j61-v6mr19023085plb.172.1535788505298; Sat, 01 Sep 2018 00:55:05 -0700 (PDT)
Received: from [192.168.2.109] ([175.156.157.4]) by smtp.gmail.com with ESMTPSA id n24-v6sm21647541pfi.161.2018.09.01.00.55.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Sep 2018 00:55:04 -0700 (PDT)
To: Robert Stepanek <rsto@fastmailteam.com>, calsify@ietf.org
References: <1535620158.162328.1491072080.2C47352D@webmail.messagingengine.com> <5eb08950-5d3a-ba80-7fdd-653f48ce5792@gmail.com> <1535637876.374476.1491356408.2B9BD317@webmail.messagingengine.com>
From: Adrian Apthorp <adrian@apthorpia.com>
Message-ID: <76c114d4-708f-7cc0-7a47-fb8206556317@apthorpia.com>
Date: Sat, 01 Sep 2018 15:55:01 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <1535637876.374476.1491356408.2B9BD317@webmail.messagingengine.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/calsify/7eV0Hj05Awn2WRhYdNPIGrOM_8s>
Subject: Re: [calsify] JSCalendar: what to do with JSTask?
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: <calsify.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/calsify>, <mailto:calsify-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/calsify/>
List-Post: <mailto:calsify@ietf.org>
List-Help: <mailto:calsify-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/calsify>, <mailto:calsify-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Sep 2018 07:55:09 -0000

I tend to agree with Mike. The core of tasks is covered in JsTask. In 
some ways specifying in json has helped to overcome some of the 
iCalendar format limitations on hierarchical data structures. i.e. it 
does away with the need for the GROUP parameter.

 From what I can see everything not included in JsCalendar, as of 
https://tools.ietf.org/html/draft-ietf-calext-jscalendar-06 but 
discussed in either 
https://tools.ietf.org/html/draft-apthorp-ical-tasks-01 or 
https://tools.ietf.org/html/draft-ietf-calext-ical-relations-04 would be 
an extension. i.e.

- status reasons
- sub-states
- refid
- gap
- new reltypes

I'm just wondering whether the link construct can somehow be used to 
achieve what refid is for?

The most recent change with statusUpdatedAt mitigates a potential future 
annoyance.

 From a quick cross-check I think many existing proprietary task APIs 
(google, ASANA, etc) could be quite happily mapped to JsTask.

Cheers


Adrian

On 30/08/18 22:04, Robert Stepanek wrote:
> On Thu, Aug 30, 2018, at 15:48, Michael Douglass wrote:
>
>> I'm currently in the process of developing an app which relies heavily
>> on tasks and the ease of translating from tasks to derived events and
>> which uses json for messaging. I think this is a vital part of the spec
>> and should remain.
> I'm happy to hear that the proposed JSTask object is already useful in implementations. My concern is: is it ripe for standardization? It looks to me as if the discussion on a "better VTODO" is split on two draft documents, and it'd be sub-optimal if the two specifications come to different conclusions. I'm not involved in the discussions around VTODO, probably my concerns are unnecessary.
>
> Cheers,
> Robert
>
> _______________________________________________
> calsify mailing list
> calsify@ietf.org
> https://www.ietf.org/mailman/listinfo/calsify

v2.23.0 | Report a Bug | By Email