The limitations of the XMLRPC getRecentPosts API call are often cited as the core limiting factor for many desktop clients. In particular, the fact that only the last "N" posts can be fetched makes it difficult or impossible to provide access to very old posts, without imposing a burden on the server.
A user's request got me thinking and I realized that the API might benefit from a very generalized "search" API that would allow for a huge variety of useful operations without bloating the API namespace too much.
For instance, the search API might take an array of "search parameters", such as:
search string - true if the body, title, etc of a post contains this string
post category/tag - only return posts in a given taxonomy
post status - useful for retrieving a list of only draft or only published items
post id - perhaps a list of post id ranges, so a client could ask for posts {10-15, 18, 21}
post date - a date range e.g. only posts from january-june of 2007
post author - this would be awesome for clients to be able to restrict listings to only the particular author
If the API took a "maximum results" parameter as well, its functionality could match exactly "getRecentPosts", if no search parameters are provided.
I think an API like this could be very powerful and also take the pressure off as far as specific requests for accessors to only get draft posts, etc.
