[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>:
>
>> Quoting Jan Schneider <jan at horde.org>:
>>
>>> Zitat von Michael M Slusarz <slusarz at horde.org>:
>>>
>>>> // $a stored in backend
>>>>
>>>> // ...
>>>
>>> In the backend should be stored a valid serialized string, but it isn't:
>>
>> Why does it need to be a valid PHP serialized string?  It doesn't.   
>> We can store whatever the heck we want in the backend.  As long as  
>> the driver knows the string translation used, it doesn't matter.
>
> But we don't store whatever the heck we want, we store a  
> standardized data format. Just broken.
>
>>>> // Retrieve in backend.
>>>> $b = $a;
>>>
>>> unserialize($b);
>>>
>>> PHP Notice:  unserialize(): Error at offset x of y bytes
>>
>> Why are you doing this?  Of course this isn't going to work - the  
>> value in the backend is not valid PHP serialized data.  But this  
>> will NEVER happen.  Nobody should EVER be directly manipulating  
>> data from the backend - to retrieve data you MUST use getValue().   
>> And by the time the user gets the preference value from a  
>> Horde_Prefs::getValue() call, the string has already been charset  
>> converted (if necessary).
>>
>> In other words:
>>
>> $prefs->setValue('pref', $foo);
>> ..
>> $bar = $prefs->getValue('pref');
>>
>> // RESULT: $prefs === $bar;
>>
>> This is all the end user cares about: Is the return from getValue()  
>> the same as the original value they stored?  The answer is yes (or  
>> at least it has yet to be proven otherwise with the new code).
>
> The approach is wrong. If we use a standard format to store stuff,  
> then we must stick to that standard and don't break it. Everything  
> worked fine that way in Horde 2 too. Until a situation popped up  
> that we didn't think of that broke everything, so we had to re-do it  
> for Horde 3. You simply don't know how we are going to access that  
> data in future, and there might be folks that access this data  
> directly. I know, this is not supported, but people will do it. I  
> know, they can convert the data themselves, but they will forget,  
> because in 95% of cases it works without.

This is not a strong argument to me.  We are supposed to support  
software/data where people are using it incorrectly?  By this logic,  
no software will ever be able to be supported.  What if someday we  
decide to compress entries?  What if we only compress large entries?   
The data storage format may be inconsistent between prefs, but we  
should be allowed to change the backend data format whenever we want  
to, and however we want to.

We provide people with APIs to correctly access the data.  If they  
choose not to use those APIs, they are on their own.  If you feel  
differently about this statement than I do, that's probably a  
fundamental difference in our thinking that can't be easily resolved.

What isn't acceptable to me is forcing a user to remember that he/she  
is responsible for doing charset conversion when saving prefs, but  
ONLY when storing PHP serialized data.  That is an absurd requirement.  
  You are forcing the 99% of the people using the API correctly to  
perform all sorts of extra work just to appease the 1% of people who  
are using the API wrong.

michael

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