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

Hi Neil,

I think we're mainly viewing JMAP from different perspectives:

* Yours seems like "a system will be built according to the (full) JMAP 
specs"
* Mine/ours is more like: JMAP can be quite useful to adapt also for 
existing systems, even if only partially implemented (Every piece of 
JMAP makes the world a little better ;-)

Both perspectives have their merits in my opinion. I am just trying to 
bring the standard(s) forward by providing some arguments to consider 
for that second perspective.

I do think this is a valid concern, given that there is a large set of 
existing systems in the area JMAP addresses. Also CardDAV/CalDAV as 
slighly related standards are mostly implemented on top of existing systems.

I agree with you that some of my points don't seem incredibly important, 
but I think we should also pay attention not to enforce JMAP-specific 
constraints if not strictly necessary.

On 08.11.21 05:47, Neil Jenkins wrote:
> 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.

I basically had in mind the additional errors cases (as described in 
your chained call response below), which a client would not need to deal 
with in an approach more similar to ManageSieve PUTSCRIPT.

>
>> * 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.

ok, fair point.

> 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.

I just found this thread 
(https://mailarchive.ietf.org/arch/msg/jmap/6u3p0fGs9cdDrBo8y6aU_8Hi2HU/) 
which does not discuss this too extensive. But I see the point Ken made, 
that both alternatives are viable, but that it would be better to go 
with one option only.

Thanks and best,
Hans-Joerg

>
>> 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
>
> _______________________________________________
> Jmap mailing list
> Jmap@ietf.org
> https://www.ietf.org/mailman/listinfo/jmap