Access to unread messages #49

Closed
wants to merge 4 commits into
from

Projects

None yet

3 participants

@NZKoz
Contributor
NZKoz commented Oct 3, 2012

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.

@mronge
Member
mronge commented Oct 8, 2012

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

@NZKoz
Contributor
NZKoz commented Oct 8, 2012

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?

@mronge
Member
mronge commented Oct 9, 2012

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?

@NZKoz
Contributor
NZKoz commented Oct 9, 2012

Yeah, I forget which clients unfortunately, but they treated them as html attachments, never saw any ill effects with setting the disposition.

@mronge
Member
mronge commented Oct 9, 2012

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?

@NZKoz
Contributor
NZKoz commented Oct 9, 2012

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 *

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.

@jwilling
Member
jwilling commented Oct 9, 2012

NSPredicates are already quite powerful. Why not base the API around that?

@mronge
Member
mronge commented Oct 9, 2012

Do NSPredicates have support for turning the predicate string into an object graph representing the predicate?

@jwilling
Member
jwilling commented Oct 9, 2012

Predicates are built for high-speed filtering using logical comparisons. That's really all they do.

@mronge
Member
mronge commented Oct 9, 2012

Ah ok, so in this case we need to output a tree of struct mailimap_search_key * for libetpan.

-(NSSet *) uidsOfMessagesMatchingCriteria:(CTSearchCriteria *)criteria

Looks good to me, I can always pick up were you've left off since you only have time for the broad strokes

@NZKoz
Contributor
NZKoz commented Oct 9, 2012

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?

@mronge
Member
mronge commented Oct 9, 2012

Sounds good

@jwilling
Member
jwilling commented Oct 9, 2012

My bad, I thought we were talking about local searches. Carry on then! :)

@mronge mronge closed this Jan 23, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment