[dev] [commits] Horde branch master updated. f174f08002872dab2019bcca58175749f598bb6a

Michael M Slusarz slusarz at horde.org
Mon Mar 3 19:30:43 UTC 2014


Quoting Michael J Rubinsky <mrubinsk at horde.org>:

> Quoting Michael M Slusarz <slusarz at horde.org>:
>
>> Quoting Michael J Rubinsky <mrubinsk at horde.org>:
>>
>>> Quoting "Michael J. Rubinsky" <mrubinsk at horde.org>:
>>>
>>>> The branch "master" has been updated.
>>>> The following is a summary of the commits.
>>>>
>>>> from: 5001def3d7521ce8cdfdcf6317a3c5617693494e
>>>>
>>>> f174f08 Fix obtaining BINARY.SIZE.
>>>
>>> To clarify, this was broken by an incorrect fix for Bug: 12992.
>>
>> This is incorrect.
>>
>> Bodypart size queries are added using the  
>> Horde_Imap_Client_Fetch_Query#bodyPartSize() method:
>>
>>    public function bodyPartSize($id)
>>    {
>>        $this->_data[Horde_Imap_Client::FETCH_BODYPARTSIZE][$id] = true;
>>    }
>>
>> As seen, the MIME ID is stored in the KEY, not the value.  Thus,  
>> this line is correct:
>>
>> foreach (array_keys($c_val) as $key) {
>>
>> Your patch (by removing array_keys()) is simply changing the code  
>> to do a bodypartsize fetch on MIME ID 1 (boolean true = integer 1)  
>> for every bodypartsize query.
>
> Well, a var_dump of $c_val, at this point in the code, shows  
> otherwise on my installation. It shows the array keys always  
> numerically indexed, starting with 0 and the values always  
> containing the mime_id.

Extremely pissed at myself since this is, indeed, the way it works.   
But the switch occurs in the iterator method -- which is not  
documented anywhere and is exactly the opposite behavior of all the  
other entries.

Really need to find a way to unit test this kind of stuff, although it  
pretty much means I need to write an entire mockup of an IMAP server  
which is very annoying.

michael
-- 

___________________________________
Michael Slusarz [slusarz at horde.org]



More information about the dev mailing list