I'm submitting this more as an request for comment than as something I actually want to see included in its current state.
We need to quickly retrieve all the unread messages for a folder and the existing methods didn't really make that possible (unless I've missed something). If there's another way of doing this, let me know, otherwise what we wanted was:
>>>>>>> send >>>>>>
4 UID SEARCH UNSEEN
>>>>>>> end send >>>>>>
<<<<<<< read <<<<<<
* SEARCH 43 44 46 47 301 545 546 548 549 550 551 552 553 554 606
4 OK Search completed (0.000 secs).
<<<<<<< end read <<<<<<
After that we fetch the size, and envelope:
5 UID FETCH 43,552,551,550,546,47,46,545,554,553,549,606,301,44 (UID FLAGS RFC822.SIZE ENVELOPE BODY.PEEK[HEADER.FIELDS (References)])
This is a rather clumsy implementation of the MailCore changes required to implement this functionality, if you could give me some feedback on the implementation strategy and coding style I'll happily update it for inclusion.
forward port the unread message fetching code
Do a folder check to ensure flags get stored immediately
Prevents loss of flags if the app terminates or otherwise doesn't call logout or expunge.
use quoted printable and disposition inline
Looks good overall. I would love to see -(NSSet *)uidsOfUnreadMessages changed to something that can do any kind of IMAP SEARCH. I know that is more than you need, but just an overall comment that we badly need support for SEARCH in MailCore
I'll send another pull request for the quoted-printable change btw, as that's pretty important for us.
I'd be happy to implement at least the message signature of a more generic method if you give me some guidance on what you'd like the API to be? I can't imagine spending hours implementing all the other options but could at least expose something for others to help out with?
I'll merge in the quoted-printable change right now manually. I'm also going to make that same fix for text parts.
How come you added the disposition type? Did you find some clients weren't display the HTML properly?
Yeah, I forget which clients unfortunately, but they treated them as html attachments, never saw any ill effects with setting the disposition.
Ok I pulled the disposition fix in as well.
About a search API, I'm not really sure. The problem is that there are such a wide variety of search options and they can be nested with AND, OR, NOT.
Check out mailimap_types_helper.h for a list of convenience functions for working with search. Do you have an ideas for a simple API to start out?
The best thing I can think of is a specific CTSearchCriteria class, which you initialize with a type and an optional value. Which in turn returns a struct mailimap_search_key *
struct mailimap_search_key *
Then you can have
-(NSSet *) uidsOfMessagesMatchingCriteria:(CTSearchCriteria *)criteria
I personally wouldn't have the time to do much more than the broad brushstrokes of this, but people could expand it to take an array of criteria, and have them be recursive for and or etc if needed.
NSPredicates are already quite powerful. Why not base the API around that?
Do NSPredicates have support for turning the predicate string into an object graph representing the predicate?
Predicates are built for high-speed filtering using logical comparisons. That's really all they do.
Ah ok, so in this case we need to output a tree of struct mailimap_search_key * for libetpan.
Looks good to me, I can always pick up were you've left off since you only have time for the broad strokes
yeah, NSPredicate doesn't feel like a good fit as we're actually composing a query to execute server side, not iterating a list of objects locally.
No promises on timeframes but will submit a new pull request with the simple search functionality when I get the chance. I'll also add [CTSearchCriteria unseenCriteria] if that sounds like a plan?
My bad, I thought we were talking about local searches. Carry on then! :)