[dev] [commits] Horde branch master updated. 76152d6a2976549c96ae0aec5b20c4669b8a68bf

[Michael M Slusarz]

Quoting Jan Schneider <jan at horde.org>:

> Zitat von Michael M Slusarz <slusarz at horde.org>:
>
>>    Remove all external charset conversion API for prefs.  Charset
>>    conversion, if needed, should be done entirely within the storage
>>    driver (prefs now assumes all in-memory prefs are in UTF-8).
>
> I don't see how this is supposed to work. This is how we used to do  
> charset conversion with prefs in Horde 2, and it failed miserably.  
> Chances for failure are fewer now, because we don't need to care  
> about different UI charsets anymore, but if you convert the  
> serialized data, instead of converting before the serialization, you  
> end up with invalid serialized strings in the storage.

Very confused.  Why would you end up with invalid serialized strings?   
Once a string is serialized, it makes no difference whether the  
charset is converted - as long as we convert the charset back when  
unserializing.

In other words, why does it matter if you call  
Horde_String::convertCharset() before serializing vs. after  
serializing?  It shouldn't matter.

This pseudocode demonstrates how Horde_Prefs works now:

=====

$data = array('août');

// Serialize in app code
$a = serialize($data);

// Call $prefs->setValue($a):
$a = Horde_String::convertCharset($a, 'UTF-8', 'ISO-8859-1');

// $a stored in backend

// ...

// Retrieve in backend.
$b = $a;

// Call $prefs->getValue($a);
$b = Horde_String::convertCharset($b, 'ISO-8859-1', 'UTF-8');

// Unserialize in app code
$a = unserialize($a);

if ($a == $data) {
     print "SAME";
}

// prints "SAME"

=====

Maybe things were broken in Horde 2 because of inconsistent charsets  
of the strings or something similar.  But if we now guarantee (or  
demand) that input into Horde_Prefs must be UTF-8, this should remove  
all ambiguities/confusion.

michael

-- 
___________________________________
Michael Slusarz [slusarz at horde.org]