Sandro Pazzi wrote:
Hi alec, but why RC don't use uid?
UID COPY <sequence uid> "folder" UID STORE <sequence uid> +FLAGS.SILENT (\Deleted) UID FETCH <sequence uid> (<params>)
... was a standard IMAP command that use directly uid instead of id of messages. In this way all the problems with gmail was resolved.
You're right, we should use such commands for better performance. I think, the reason is in imap.inc which supports only message IDs in iil_C_Copy and some others. I don't know why IlohaMail does that is such way. We should definitely use UIDs where possible.
Do you think that is possible to implement a fast workaround for my issue in the current RC trunk. In this way I can download the lastest trunk without modify all times the imap.inc file.
Thanks
On Thu, 23 Apr 2009 11:46:53 +0200, "A.L.E.C" alec@alec.pl wrote:
Sandro Pazzi wrote:
Hi alec, but why RC don't use uid?
UID COPY <sequence uid> "folder" UID STORE <sequence uid> +FLAGS.SILENT (\Deleted) UID FETCH <sequence uid> (<params>)
... was a standard IMAP command that use directly uid instead of id of messages. In this way all the problems with gmail was resolved.
You're right, we should use such commands for better performance. I think, the reason is in imap.inc which supports only message IDs in iil_C_Copy and some others. I don't know why IlohaMail does that is such way. We should definitely use UIDs where possible.
Sandro Pazzi wrote:
Do you think that is possible to implement a fast workaround for my issue in the current RC trunk. In this way I can download the lastest trunk without modify all times the imap.inc file.
I've made a patch, but it should be well tested before merge
I alec, thanks a lot.
If u'll send me the files I'll test in my enviroment.
Thanks
On Thu, 23 Apr 2009 14:41:39 +0200, "A.L.E.C" alec@alec.pl wrote:
Sandro Pazzi wrote:
Do you think that is possible to implement a fast workaround for my
issue
in the current RC trunk. In this way I can download the lastest trunk without modify all times the imap.inc file.
I've made a patch, but it should be well tested before merge
-- Aleksander 'A.L.E.C' Machniak http://alec.pl gg:2275252 LAN Management System Developer http://lms.org.pl Roundcube Webmail Project Developer http://roundcube.net
--- 8< --- detachments --- 8< --- The following attachments have been detached and are available for viewing. http://detached.gigo.com/rc/q9/AEdvT+XS/uid.diff Only click these links if you trust the sender, as well as this message. --- 8< --- detachments --- 8< ---
Hi alec, I'm testing your patch form 1 day and all seems ok except that for the confirmation of reading message. When I send the confirmation I get an error.
Thanks
On Thu, 23 Apr 2009 14:41:39 +0200, "A.L.E.C" alec@alec.pl wrote:
Sandro Pazzi wrote:
Do you think that is possible to implement a fast workaround for my
issue
in the current RC trunk. In this way I can download the lastest trunk without modify all times the imap.inc file.
I've made a patch, but it should be well tested before merge
-- Aleksander 'A.L.E.C' Machniak http://alec.pl gg:2275252 LAN Management System Developer http://lms.org.pl Roundcube Webmail Project Developer http://roundcube.net
--- 8< --- detachments --- 8< --- The following attachments have been detached and are available for viewing. http://detached.gigo.com/rc/q9/AEdvT+XS/uid.diff Only click these links if you trust the sender, as well as this message. --- 8< --- detachments --- 8< ---
Sandro Pazzi wrote:
Hi alec, I'm testing your patch form 1 day and all seems ok except that for the confirmation of reading message. When I send the confirmation I get an error.
I don't see a reason. It was working before applying my patch? What error? Uncoment console() calls in lib/imap.inc, and show logs/console content here.
Hi Alec, I have also download the lastest trunk. The imap console end at login succes. No sending action can be seen.
Thanks
On Fri, 24 Apr 2009 13:37:24 +0200, "A.L.E.C" alec@alec.pl wrote:
Sandro Pazzi wrote:
Hi alec, I'm testing your patch form 1 day and all seems ok except that for the confirmation of reading message. When I send the confirmation I get an error.
I don't see a reason. It was working before applying my patch? What error? Uncoment console() calls in lib/imap.inc, and show logs/console content here.
Hi Alec, it's was very strange...
Logging I notice that the error was at line 1372 of program/steps/mail/func.inc: if ($message->headers->mdn_to && !$message->headers->mdn_sent && ($IMAP->check_permflag('MDNSENT') || $IMAP->check_permflag('*')))
the $IMAP->check_permflag('MDNSENT') || $IMAP->check_permflag('*') return always false but I use this functionality some day ago.
Commenting this line all works fine.
A gmail imap problem?
hope this usefull.
Thanks
On Fri, 24 Apr 2009 13:37:24 +0200, "A.L.E.C" alec@alec.pl wrote:
Sandro Pazzi wrote:
Hi alec, I'm testing your patch form 1 day and all seems ok except that for the confirmation of reading message. When I send the confirmation I get an error.
I don't see a reason. It was working before applying my patch? What error? Uncoment console() calls in lib/imap.inc, and show logs/console content here.
Hi Alec, I've tried your patch for 1 week. 4 user in gmail acconut.
It's work perfect.
Thanks
On Thu, 23 Apr 2009 14:41:39 +0200, "A.L.E.C" alec@alec.pl wrote:
Sandro Pazzi wrote:
Do you think that is possible to implement a fast workaround for my
issue
in the current RC trunk. In this way I can download the lastest trunk without modify all times the imap.inc file.
I've made a patch, but it should be well tested before merge
-- Aleksander 'A.L.E.C' Machniak http://alec.pl gg:2275252 LAN Management System Developer http://lms.org.pl Roundcube Webmail Project Developer http://roundcube.net
--- 8< --- detachments --- 8< --- The following attachments have been detached and are available for viewing. http://detached.gigo.com/rc/q9/AEdvT+XS/uid.diff Only click these links if you trust the sender, as well as this message. --- 8< --- detachments --- 8< ---