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

From: Adrian Apthorp <[email-masked]>
Date: Sat, 1 Sep 2018 15:55:01 +0800

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify