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

[Chuck Hagenbuch]

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>:
>>>
>>>> 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.
>
> Even then, we are are rarely storing huge serialized hashes in the  
> prefs. Did you profile if this has any measurable influence on an  
> avarage page load?
>
>> 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.
>
> Right, this shouldn't keep us from using json. If we serialize  
> anything but hashes/stdClasses or arrays, that should be fixed  
> anyway. The inconsistency argument still holds though. I don't think  
> it's a good idea to have 2 or 3 different serialization methods in  
> the prefs. If the json serialization has a worthwhile performance  
> improvement in a real-life situation, we might consider switching to  
> json altogether.

I do like JSON vs. tab/newline strings, and for people not comfortable  
with json, I think that's where we should get a UI on top of this  
(like config files).

So I'm fine with switching everything over.

-chuck