[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