Hi Neil,

Le mardi 18 octobre 2016 00:18:24 UTC+2, Neil Jenkins a écrit :
>
> I don't think this should be added to the JMAP spec. One of the concerns 
> raised by a large mailbox provider we talked to was to make sure a client 
> could be rate limited in a reasonable manner, so it can't overload the 
> server. (We've also been careful the other way to try to ensure the client 
> can control exactly how much data it requests from the server in one go.) 
> Adding a command like this means the client could ask the server to do 
> something potentially very expensive, depending on backend implementation.
>

Do people expect to use JMAP as the only protocol to access mailboxes ? 
because in IMAP, such very expensive methods are very common (expunge, 
modification with a very broad uid range, etc).
 

>
> Now the server could reject it if it's over a certain number of messages 
> resulting in the query, but the exact limit will be server dependent and 
> when it happens the client has to fallback to a different approach. Having 
> two different implementations in the client is likely to be less tested and 
> buggier.
>
 

>
> In general, JMAP prefers the philosophy of explicitly telling the server 
> what changes to make; this is often more efficient anyway if you're keeping 
> the client cache in sync.
>

You can do that with IfInState easily, you already know which messages will 
be changed client-side because you actually wrote the query.
 

>
> The approach we take to this problem (and I would recommend) is to fetch 
> the list of ids up front (in pages if necessary), then ask the server to 
> make the changes to them in batches (say 100 to 500 at a time), waiting for 
> the previous request to finish before making the next one.
>

It doesn't look like a great API to me. Managing deletion with client-side 
batch for performance purpose doesn't sound good.
I think a good implementation will consume more ressources to handle such 
large queries than to do it server-side based on a query.
 

> The ids (should be) reasonably small and quick to fetch even for large 
> folders. Fetching them up front ensures you don't process anything that 
> arrives during the operation. 
>

IfInState already covers this case, don't you think ?
 

> By doing it a batch at a time, you can make sure you won't overload the 
> server (and make sure the server will accept the request), and also more 
> easily show a progress bar to the user (because the user is probably locked 
> on the server while the changes are being made), or even interleave other 
> requests to keep the client responsive while a large operation is happening 
> in the background.
>

It would be easily solved with an "async" capability on requests. We 
already have Event Source for receiving async result. What do you think ? 

>
[...] 

Regards,

-- 
Matthieu Baechler

-- 
You received this message because you are subscribed to the Google Groups 
"JMAP" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jmap-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to jmap-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jmap-discuss/91dc3a56-0cf9-43b8-9a3c-f165d0027e39%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to