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

[Jan Schneider]

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.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/