Re: [calsify] Request for adoption: draft-gondwana-caldav-scheduling-controls

[Ken Murchison <[e-mail]>]

On 3/26/19 12:39 PM, Michael Douglass wrote:
>
> I think it probably would bear some investigation.
>
> I suspect the bulk import would work better for the special cases you 
> mentioned.
>
> My recollection is that you get some sort of per record status and 
> that would be helpful.
>

Yes, bulk import as defined in the Daboo draft uses a 207 (Multi-status) 
response.



> Maybe we should talk about this - I see some other less importy uses - 
> for example updating a whole bunch of related resources. That gets 
> very messy if it has to be done as a bunch of requests and one of them 
> fails.
>
> On 3/26/19 07:16, Ken Murchison wrote:
>>
>> To clarify, I implemented bulk import only.  I haven't implemented 
>> bulk update.
>>
>>
>> On 3/26/19 5:54 AM, Bron Gondwana wrote:
>>> Thanks Mike - sorry about the delay in replying.
>>>
>>> Do you think we should progress bulk-change as a separate document, 
>>> or merge it into scheduling controls?
>>>
>>> Ken implemented it in the Cyrus IMAPd server, but we aren't using it 
>>> ourselves.  I guess you could "bulk update" a single item to avoid 
>>> scheduling as an alternative method.
>>>
>>> Bron.
>>>
>>> On Sat, Mar 9, 2019, at 07:38, Michael Douglass wrote:
>>>>
>>>> Cyrus wrote a spec for bulk import/updates
>>>>
>>>> https://github.com/apple/ccs-calendarserver/blob/master/doc/Extensions/calendarserver-bulk-change.xml
>>>>
>>>> I have the impression it's used but not certain.
>>>>
>>>> The spec says nothing about scheduling.
>>>>
>>>> On 3/8/19 07:07, Bron Gondwana wrote:
>>>>> It's a bit cheeky asking this as a recent chair myself, but I had 
>>>>> started work on this document as a purely FastMail suggestion, and 
>>>>> during discussion at CalConnect last month in Zurich it came up 
>>>>> that Google had done much the same thing themselves to handle bulk 
>>>>> import, so I ran the idea past Lucia and put this draft together.
>>>>>
>>>>> There's still some work to do, and I'm happy to hand over 
>>>>> authorship to somebody else if anyone wants it, or to continue 
>>>>> working on it myself.  I've renamed things to be a bit more 
>>>>> consistent than our implementation at FastMail, but of course we'd 
>>>>> update to match the standard once the spec is done.
>>>>>
>>>>> https://datatracker.ietf.org/doc/draft-gondwana-caldav-scheduling-controls/
>>>>>
>>>>> (still plenty of work to do on it, but the bones are there)
>>>>>
>>>>> I believe this is within the scope of this group's existing 
>>>>> charter and would like to see it adopted.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Bron.
>>>>>
>>>>> --
>>>>>   Bron Gondwana, CEO, FastMail Pty Ltd
>>>>> [e-mail] <mailto:[e-mail]>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> calsify mailing list
>>>>> [e-mail]  <mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/listinfo/calsify
>>>>>
>>>> _______________________________________________
>>>> calsify mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/calsify
>>>>
>>>
>>> --
>>>   Bron Gondwana, CEO, FastMail Pty Ltd
>>> [e-mail]
>>>
>>>
>>>
>>> _______________________________________________
>>> calsify mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/calsify
>> -- 
>> Ken Murchison
>> Cyrus Development Team
>> FastMail US LLC
>>
>> _______________________________________________
>> calsify mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/calsify
>
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC