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
> 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 ?
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to email@example.com.
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.