Re: [dispatch] Potential incoming work: web push for IMAP, CalDAV and CardDAV

[Julian Reschke <[e-mail]>]

On 24.10.2019 11:34, Michael Toomim wrote:
> Thank you very much for your early comments!
>
> Julian:
>>
>> Hmm. I think you'll need to work on the proper labeling of things. Even
>> if the client opts into this format, the Content-Type will still have to
>> describe the overall payload.
>
> Hm, I think I see where you're coming from.  Here's the example in my mind:
>
> Request:
>       GET /animated-braid.gif
>       Subscribe
>
> Response:
>       OK 200
>       Subscribe
>       Cache-Control: no-cache
>       Patch-Type: braid-patch(bytes, sync9(array))
>       ---- Part 1
>       Content-Type: image/gif
>       Patch-Type: braid-patch(bytes, sync9(array))
>       Content-Length: 1239
>
>       [100:200] = <binary data>
>       ---- Part 2
>       Content-Type: image/gif
>       Patch-Type: braid-patch(bytes, sync9(array))
>       Content-Length: 62638
>
>       [348:887] = <binary data>
>
> I think you're saying that the Content-Type of each part should need to describe the BODY of each part.  Why is that necessary?  I would imagine that it would only impact a cache, but we rule out caches with no-cache unless they understand the patch format.

Not necessarily every part...

> It seems to me that the Content-Type *could* conceivably describe the semantic content of the resource, even though its updates are described with a particular Patch-Type.  Similar to how Range Requests don't change the Content-Type, even though they are only sending a small patch of the object in the BODY.
>
>> You're basically inventing a new payload format that can wrap multiple
>> payloads. But then we already have multipart/*; it really seems to me
>> you should be using that instead.
>
> I'm open to using multipart/*.  Are there any advantages to it?  It requires the sender to come up with a unique separator string, which means they need to scan all messages before choosing the separator to wrap them with.  It seems simpler to just use Content-Length: N to communicate how to break apart multiple messages, and as a bonus, you can stream the data and process just one message at a time.
>
> Thank you very much for your early comments!

And the end of the day, this is still HTTP. The response needs a media
type that describes the payload. You are defining a new payload format
that can handle multiple resources, so you need a container-like format.
multipart can do that, but I agree the mail format legacy with the
boundary string is sub optimal.

But then, sending Content-Length inside the payload is a bit weird as
well; it defeats streaming the part; you may want to consider a binary
container format instead (based on HTTP chunked, for instance).

Best regards, Julian