The problem: WHEREIS must come after PREPARE, and external remotes are encouraged to establish network connections in PREPARE to simplify their implementations. So `git annex whereis` with such an external remote enabled and content on that remote is slowed down by an unnecessary network connection. Note that this even happens when the external remote does not implement support for WHEREIS. So, we want to deprecate WHEREIS needing to come after PREPARE. GETINFO has the same problem. (GETCOST and GETAVAILABILITY also, but those are cached to avoid needing to be run more than once per remote.) The transition: * Add an extension to the protocol that lets WHEREIS come before/without PREPARE. The external remote can indicate it supports this by negotiating EXTENSIONS WHEREIS. And similarly for GETINFO, with EXTENSIONS GETINFO. * For a while, git-annex can continue to send WHEREIS after PREPARE when the external remote doesn't support the protocol extension. If the external remote replies with WHEREIS-SUCCESS, then git-annex can warn that it needs to be updated for the transition. (If it replies with WHEREIS-FAILURE, it may be that it only has stub whereis support that doesn't do anything, so probably git-annex should avoid warning in that case). And similarly for GETINFO, warning when it is sent after PREPARE and there are any INFOFIELD replies, but not warning if there's only an INFOEND. * Eventually, git-annex can stop sending WHEREIS unless the protocol extension was negotiated. So WHEREIS stops being part of the base protocol and becomes an extension. Ditto for GETINFO. Possible complications: An external remote may need to do some kind of expensive setup to prepare to reply to WHEREIS, such as querying with GETCONFIG or looking at its own internal state or whatever. With WHEREIS run before PREPARE, such a remote will need to defer that setup until the first WHEREIS and cache it for subsequent WHEREIS, which may complicate its code slightly. Note that the protocol does allow querying with GETCONFIG etc before responding to a WHEREIS request. [[!tag confirmed]]