Thanks for raising this topic, because we did discuss it in a lot of detail, and we actually decided to go entirely the opposite direction! Instead of deleting a mailbox causing the messages to be moved to the "inbox" role if there were messages in the mailbox, we changed it so that you can't delete a mailbox which contains messages. You need to explicitly delete them or move them out first.
There are some strong guiding principles in JMAP, and one of them is that messages are precious and actions should be explicit.
Our own Cyrus IMAPd server has algorithms built on the assumption that the biggest single mailbox will contain one million emails. That's pretty big. We have around 20 users with more than that many emails total across all their mailboxes (I know because we have a 32 bit file size issue with an internal cache file when you get to about 3 million messages in a single mailbox).
So looking at a most extreme case of deleting a million emails at the same time, you're looking at one megabyte per byte of message. A reasonable ID size is 64 bits, which is 16 hexadecimal characters. Add in commas and quotes, you're looking at roughly 20 bytes per id. Multiply that by a million, that's 20 megabytes of IDs to download and process.
Yes, it's a lot of data. But 1 million emails is nearly 2 years' worth of getting one email per minute, all day, every day, and not deleting anything right up until you suddenly decide to wipe all million emails.
A more realistic number is 10,000 emails in a mailbox which is being wiped. That's a week of one email per minute, which is about twice the rate that I get (and I get a ton of notify email and mailing lists).
10,000 IDs is 200kb of data. Half the webpages I go to are about that size. And that's once per week on a really busy account, where you're downloading tons more data than that just to keep up with reading a fraction of your incoming email.
So I'm not convinced that this "inefficiency" is actually a problem in practice. The code to fetch the list of IDs and pass it back to the server isn't complex. As Neil said, batching in groups of say 1024 messages allows you to display a progress bar as you delete the messages. Implementing an "empty Trash" as a callback which gets all the IDs in the Trash folder and issues a delete for them all isn't much client side code, and it means that the protocol doesn't have the discontinuity.
It would be easy to implement an extension for "emptyMailbox" (which I think is the use case we're really looking for here, rather than arbitrary filter), but I've been convinced upon further examination that it shouldn't be in the base protocol.
Regards,
Bron.
--
Bron Gondwana