Re: [Jmap] [Jmap for Sieve] Binary/blob vs. Inline

[Neil Jenkins <[e-mail]>]

On Sat, 6 Nov 2021, at 03:37, Hans-Joerg Happel wrote:
> While this is no strict blocker, I think enforcing a blob storage concept so widely is in conflict with the goal of making it easy for as many people as possible to adopt JMAP.
> 

Blob support is a part of JMAP core, so if you want to implement JMAP you're probably going to need it.

> * The blobId approach opens up many potential error cases, which server+client implementers need to have in mind (e.g, think about the script validation workflow)

Not sure I follow. You validate it just the same, it's just where you get the bytes from.

> * It makes the JMAP Sieve workflow essentially different from the known and closely related ManageSieve workflows 

Making it work the same as ManagedSieve is secondary to making it work consistently with other JMAP APIs in my view.

I personally don't particularly mind whether the API is blob based or just inline code, but I know this was discussed earlier and I believe there were good reasons to go with blob.

> If I understand it correctly, while it is atomic from a HTTP call perspective, the chained processing of commands on server-side is not necessarily atomic from a logical point of view?
> 

That's right.

> Which would mean that a client still needs to deal with different cases (partial fail / complete fail ... ) of the chained calls?

Well, it can probably just look at the response of the second call; if the blob creation succeeded but the sieve update failed, you can just ignore the blob bit; it should get cleaned up at some point automatically. And if the blob failed, then the sieve update will fail as the result ref won't resolve, so you can still just look at the second error.

—Neil