[dev] RFC: array values for preferences

[Jan Schneider]

I'm currently trying to fix the problem that serialized arrays getting
stored in an sql backend may contain invalid characters for the charset that
the backend use. This problem mainly exists in the category and the
preferences system.

But only in the prefs I've found a real problem. To change the least amount
of code possible I convert the prefs values' charsets in
retrieve/store/get/set. This doesn't work with serialized arrays because the
string lenghts might change during a charset conversion, corrupting the
serialized array.

The easiest workaround would be to allow the preference system to not only
accept scalar values but also (unserialized) arrays that get serialized
automatically. 

This had two consequences: 

- As we don't know the possible structure of the array (it might even be a
multidimensional one) we had to walk through the array's values and convert
each them separately. This works fine as long as the value is either in
ascii (the case with all enum/true-false/numeric preferences we provide) or
from a user input (where we know the charset he uses). It might get
problematic if we have preference values from a third source. Do we?

- We need to automatically unserialize preferences if they match
/^a:\d:\{.+\}$/ in hope that we don't catch any strange preferences that
match it too but aren't serialized arrays (unlikely).

- We need to change every piece of code that deals with serialized arrays as
a preference and _might_ contain non-ascii characters. Looking at my
personal prefs this currently seem to be filters, identities, prefbooks,
rules and eventually portal_layout.

Btw, noone responded so far to my question how we should deal with login
data (user names and passwords). Do we have to assume that non-ascii
characters are allowed and actually used?

Jan.

--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft