On Wed, 07 May 2014, Dionysios Kalofonos wrote:

> > * Change current custom commands to be an override of LIST
>
> I have been working a bit on this and i have introduced the function
> imap_perform_custom (attached).
>
> Do you prefer that or overriding LIST?

I was hoping that we wouldn't need a imap_custom_function() but didn't want to override LIST like we currently do.

> > * Implement custom command support for FETCH
> > * Implement custom command support for APPEND
>
> Could you please elaborate on these? I do not understand them.

I thought that the UID would still be passed in via the URL so the imap_perform_fetch() would be called as it is now.

It then tests to see if there is a custom string set and sends that to the server instead of the FETCH.

Obviously the decision logic in imap_perform() and imap_state_select_resp() would need to change to something like:

  /* Start the first command in the DO phase */
  if(conn->data->set.upload)
    /* APPEND can be executed directly */
    result = imap_perform_append(conn);
  else if(selected && imap->uid)
    /* FETCH from the same mailbox */
    result = imap_perform_fetch(conn);
  else if(selected && imap->query)
    /* SEARCH the current mailbox */
    result = imap_perform_search(conn);
  else if(conn->data->set.ftp_list_only)
    /* LIST */
    result = imap_perform_list(conn);
  else
    /* SELECT the mailbox */
    result = imap_perform_select(conn);

As I kind of mentioned above, each of these function then test map->custom and does the appropriate thing.

> > The only thing I'm not 100% sure about in my own head is what to do
> > with the following URL for example:
> >
> > imap://imap.example.com/INBOX
> >
> > Currently it will performs a LIST command, but Section 5 of RFC-5092
> > suggests (if I have understood it correctly) using it to perform a
> > SELECT or EXAMINE command.
>
> Hence if we intend for this url to be used more freely by the client
> maybe an EXAMINE is more appropriate.

Mmmmm. Definitely food for thought.

> > imap://imap.exmaple.com/INBOX --next
> > imap://imap.example.com/INBOX/;UID=1
> >
> > Would be the same as:
> >
> > imap://imap.example.com/INBOX/;UID=1
>
> Using --next the client gets the response of both urls, right? Hence,
> the client would get also the response of the SELECT/EXAMINE
> which includes the uidvalidity, total (EXISTS), and uidnext among the rest.

Of course - yes.

> > Which seems a little pointless on its own, however, it could be used
> > to periodically check the UID validity of a mailbox:
> >
> > imap://imap.exmaple.com/INBOX;UIDVALIDITY=50
>
> On the contrary, now the client has to issue a custom SELECT/EXAMINE
> request to get the uidvalidity. Stopping at the SELECT/EXAMINE is not
> that bad is it may seem.

True.

I hope the first part of the email / code snippet helps explains my thought process a little more.
 
Cheers

Steve

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-05-07