[dev] [commits] Horde branch newprefsui updated. 28ee4e1e04b5f112d4a308cda5c42053d61e412c

[Michael M Slusarz]

Quoting Jan Schneider <jan at horde.org>:

> Zitat von Michael M Slusarz <slusarz at horde.org>:
>
>> Quoting Jan Schneider <jan at horde.org>:
>>
>>> Zitat von Michael M Slusarz <slusarz at horde.org>:
>>>
>>>> commit 2b3abe74f295dcedc13498a2c86131c493977d4b
>>>> Author: Michael M Slusarz <slusarz at curecanti.org>
>>>> Date:   Wed Apr 7 09:17:03 2010 -0600
>>>>
>>>>  Convert turba addressbooks pref to json format
>>>
>>> Why, what's wrong with the current format, that doesn't require an  
>>> upgrade step?
>>
>> It was a PITA to convert to/from the old serialized format, and  
>> then convert this intermediate object to the javascript format.   
>> The code completely failed my general test: I couldn't reliably  
>> figure out what the chunk of code was doing even after staring at  
>> it for a few minutes.
>>
>> Just as important, it is *much* easier for an admin to set a  
>> default value, rather than using tabs and newlines.
>> Providing an example that looks like this:
>>
>> json_encode(array(
>>    'foo1' => array(
>>        'bar1',
>>        'bar2'
>>    ),
>>    'foo2' => array(
>>        'bar3'
>>    )
>> ))
>>
>> is much easier to visually parse than this (especially since all  
>> the rest of our configuration files are array/hash based, so an  
>> admin necessarily is familiar with the PHP array data structure):
>>
>> "foo1\tbar1\tbar2\nfoo2\tbar3"
>
> I'm not sure, especially since the current format is easy to  
> understand even for not-php-capable admins.
> What I find more irritating though is, that you added yet another  
> serialization format to the prefs. I see how it's easier for the  
> implementation to use a native serialization format, but then we  
> should stick to PHP's serialization like we do anywhere else in the  
> prefs, instead of introducing JSON serialization.
> Alternatively we might consider switching to JSON altogether because  
> that's easier to write and understand than PHP's machine-readable  
> serialization. But I'm not sure if I really want to open this can of  
> worms.

Can of worms is already open.  I have already used json_encode for IMP  
flags.  The advantage is that json encoding is *much* more efficient.   
We are not talking slightly more efficient, we are talking about more  
efficient by ~250%.

Quick example.  This script:

<?php
$a = array();
for ($i = 0; $i <= 1000; ++$i) {
     $a[strval($i)] = array(
         'a' => 1,
         'b' => 'foo',
         'c' => array(1, 2)
     );
}

print 'Serialize size: ' . strlen(serialize($a)) .
     "\n".
     'json_encode size: ' . strlen(json_encode($a));
?>

Serialize size: 71972
json_encode size: 28029

For something like IMP's flag array, if you have tens of thousands of  
users potentially using a non-default value, the serialization savings  
adds up.

Obviously, you can't use json_encode() if we are serializing something  
other than a string, number, array, or stdClass object.  But in the  
prefs file, I doubt we are serializing something besides those items.

michael

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