Re: [SM-DEVEL] problem with deleting the wrong mail

[Marc G. K. <ma...@it...>]

> Marc Groot Koerkamp said:
>>>>>   So in devel you have UID's referenced from the checkboxes on the
>>>>> mailbox
>>>>> display?
>>>>
>>>> Exactly.
>>>
>>> hmm... So to use the UID instead of the message sequence number you
>>> change all the IMAP calls to return UIDS instead of the message number
>>> for say the $server_sort_array ? Sounds like most of the work would be
>>> at the IMAP communication level. Once I get done with the
>>> register_globals fixes I will take a closer look at the code. Thanks
>>> for the example btw. I never access my mailbox with more than one mail
>>> client at a time which explains why I have not run into this before.
>>> One more question. Can you think of a scenerio in which this problem
>>> could occur when accessing your mailbox with only one instance of SM?
>> You mean only one imap-client connected to the specific mailbox.
>>
>> No not realy, but it is possible to view and reply to shared mailboxes
>> so you don't realy know who else has access to the same mailbox at the
>> same time.
>>
>> The problem with ID instead of UID is that the ID <-> message
>> relationship is only garantied at the moment you fetch the header / id's
>> or message / id. A split second later you can't know for sure that the
>> relationship is still a valid relationship. That's why UID-support is so
>> important.
>>
>> Please have a look at how it is implemented in devel. Thijs Kinkhorst
>> also want to take a look at it.
>> If UID-support is working for all imap-servers then we should adapt the
>> queries instead of make use of the global $uid_support.
>>
>> So I suggest that we first get the thing working in devel for all
>> imap-servers and after that the port to STABLE is "simple".
>> The option uid_support should disappear and SM should default make use
>> of UID instead of ID.
>>
>> It's already working on cyrus. Problems with other servers has probably
>> something to do with sqimap_get_small_header_list and the matching of
>> the "UID nnnn"  string.
>>
>> Another big advantage of UID is that cached information stays valid. If
>> we cache the header_list and change the mailbox then we should store
>> already cached information in a cache per mailbox way. (and also
>> remember UIDNEXT)
>>
>> Switching back to the already cached mailbox is much quicker because we
>> only have to fetch:
>> 1: fetch 1:* UID FLAGS   (much quicker then fetching all the small
>> header-stuff) 2: fetch UIDNEXT:* (UID BODY.PEEK[HEADER (blah blah)])
>> (new messages since the last fetch)
>>
>> and update the cache with the found information.
>>
>> Regards,
>>
>>
>> Marc Groot Koerkamp
>
> Ok, so I lied, I have more questions :)
>
> If we can finish the register globals = Off fixes in the next week, then
> get UID support working in DEVEL the week after, then port it to STABLE +
> add some testing time and translation updates we could release the next
> STABLE version in say 3 weeks with UID support.
>
> Should we do this?
> Is this problem serious enough to make those kind of drastic changes to
> the stable code?
> Base on this thread and my gut feeling I would say yes, but what do other
> developers think?
>
You know how I think :-)

The implications are a bit "drastic" for the non_server_side_sort and
non_thread_sort way of displaying the messages in mailbox_display and sort=6
(=no_sort).

For the rest the changes are minor. the fetches changes to sid UID FETCH, the
store / delete /flags related imap calls changes to UID <command>.

we already store the ID but with UID support it is a UID.

See it for yourself in the uid_support related changes in the CVS. Most of the
changes has to do with supporting non-uid_support as well uid_support.

If everything works well in devel the only functions which needed to be
adapted in STABLE are NextMessage / PrevMessage in read_body, and
mailbox_display.
The rest are minor changes at imap_level.



>
>
>  \___ Jason Munro
>   \___ AIM:jmunr0
>    \__ ja...@st...
>     \__ http://www.sunflower.com/~jmunro/
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Dice - The leading online job board
> for high-tech professionals. Search and apply for tech jobs today!
> http://seeker.dice.com/seeker.epl?rel_code=31
> --
> squirrelmail-devel mailing list
> List Address: squ...@li...
> List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel
> http://squirrelmail.org/cvs
>