No real support for async activity. Take update_file_info - if you return OPERATION_IN_PROGRESS, Nautilus will wait until the callback is invoked before processing the next one. You can't get the whole list, do the stuff in the background, and return results one by one. Once you invoke the callback, there is absolutely no way to know when the Nautilus window is closed. It will tell you to cancel something if it's waiting for a result, but not if you've already given it one.

You can't update things unless you keep a hold of EVERY FileInfo item it gives you. These are not serialisable, so your memory usage is rooted. Because Nautilus won't tell you when it doesn't need them any more, you can't discard them when they're not needed.

Background menu updating is far too coarse. It goes like this:

1. Nautilus requests background items for a single directory
2. We give it a “Please wait” item to display
3. We compute the result
4. We use the provider handle to emit the “items-updated” signal
5. Nautilus re-requests the menu for every single open window! What. The. What.

So this means we need to keep the information for every single directory opened by Nautilus for the current session! Just for when we update the menu for ONE of them!

There's just no real cohesion between the methods. If we want to asynchronously update file information, we need to cache weird item objects and call an invalidation method on them. If we want to asynchronously update parent dir information, we need to keep a similarly weird provider instance (that, incidentally, never changes) and call a method on that. Which updates everything at once. The first is per node, the second is per extension.