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

[Hans-Joerg Happel <[e-mail]>]

On 26.10.21 06:43, Neil Jenkins wrote:
> On Fri, 22 Oct 2021, at 03:41, Hans-Joerg Happel wrote:
>> => We'd argue that this process is both complex to implement plus it's
>> not particularly elegant to create a need for storing a temporary file.
>
> Depends how you look at it; it /is/ elegant to have a single 
> consistent method for referencing binary data. I think the answer here 
> if you are trying to add support on a legacy system where this is 
> difficult is to make the Sieve its own account. Then when you upload a 
> blob to that account you know it can only be a sieve script, which 
> should allow you to do something reasonable.

Thanks for elaboration - I missed to recognize that it is possible use 
the "Account-workaround" also for writing.

However, enforcing this process makes it still hard to implement in 
various imaginable cases. Take my initial Database storage example: You 
might force an implementer to store a temp Sieve script (from blob call) 
until the second call comes in to continue glue together that data and 
do the database INSERT.

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.

Some additional minor points, for the record:

* 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)
* It makes the JMAP Sieve workflow essentially different from the known 
and closely related ManageSieve workflows


>
>> It would therefore be good if it is possible to (alternatively?) submit
>> the script inline in the "SieveScript/set" command instead of a blobid.
>
> Using Bron's blob extension you can create a blob in-band and then 
> backreference it from the SieveScript/set command. But I wouldn't want 
> to say that was the only way you could do it; that breaks the 
> consistency of the blob handling.

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? Which would mean that a 
client still needs to deal with different cases (partial fail / complete 
fail ... ) of the chained calls?

Best,
Hans-Joerg