Re: [Jmap] Review: draft-murchison-jmap-sieve-01

[Ricardo Signes <[e-mail]>]

On Wed, Jul 8, 2020, at 8:22 AM, Bron Gondwana wrote:
> *Open issues:*
> 
> /set#create should fail if there's already a script with the same name. The JMAP request can include a "destroy" for the ID of the old script, or it can issue an "update" on the Id of the script with the same name to replace the content.

Well, you already know this doesn't get me what I want, but I have a suggestion. :-) First, my complaints:

This leads to more HTTP transactions than is otherwise necessary.

Say that from a position of ignorance of the remote state, I want to set my active Sieve script to the document S. This requires this set of interactions:

• HTTP request 1: SieveScript/get
• locally extract the id of the active script
• HTTP request 2: SieveScript/set { update: { activeId: { script: $NEW, isActive: true } } }

This is an extra round trip. (So the re-set of isActive at the end is to avoid a race. An ifInState would also do the trick.)

This would not be required in managesieve, where by convention the client could control the script name and know that a PUTSCRIPT for the conventional name would update the active script. The shift from client-controlled keys (script names) to server-controlled keys (JMAP ids) eliminates the possibility for this kind of convention. 

You suggest that the client can perform either a destroy-and-create or an update but I think that *only the update-based operation is safe*. Consider:

• client does a SieveScript/get and determines the active id script is "123"
• client issues SieveScript/set { destroy => [ "123" ], create => { newScript => { …something invalid… } } }

Because the create and destroy may be applied independently, the user could end up with no active script at all. This is too bad, because otherwise you could provide SieveScript/query (which would need to be invented), backreference the results for (filter:{isActive:true} OR name:NameWeWant) in a destroy, and create the replacement in the same breath, which would be safe. 

*I suggest instead*:

1. We drop isActive as a property from SieveScript.
2. We create a new type, SieveConfig
3. SieveConfig has exactly one instance per account, with the fixed id "singleton"
4. The SieveScriptConfig object has one property, activeScriptId, which is either a script id or null
5. If no "name" is provided, the server will provide a guaranteed unique name.

To replace the active Sieve script in the blind, you do this:

SieveScript/set { create: { newScript: { content: "..." } } }
SieveConfig/set { update: { "singleton": { activeScriptId: "#newScript" } } }

This is guaranteed safe. The worst case is that you end up with a uniquely-named script that is not, in fact, active.

We probably also need:

6. If the active script is deleted, the SieveScriptActive activeScriptId becomes null.

Alternatively, it could be illegal to destroy the active script.

*As for everything else…*

I agreed with all the rest of your points.

If we add SieveScript/query as you suggest, then this pair of methods would get tacked onto my couplet above:

SieveScript/query { filter: { isActive: false } }, A
SieveScript/set { "#destroy": { backreference-to-A-list } }

-- 
rjbs