As always, thanks for the comments!
The cookie idea: it's a good idea, as long as we make sure to
keep the # and size of cookies to a minimum. What is probably
better (and related) is to keep a cache of preferences on the
server side keyed by session ID so that we only have to load up
the preferences once for a particular user. Let's keep this one in
the back of our mind for when we start optimizing.
Simon, we definitely want to allow package-instance-specific
preferences. No question there. I think there is one thing to think
about: system-wide preferences that all packages can tap into.
This is probably the hardest part of it all: we don't want the core
preference type list to grow in an outrageous manner, but we
also don't want individual packages to have redundant
preference types because of a lack of core preference types.
For example, it's probably a good idea to store "Data Newness"
in the core, so that a user can say that she wants all data older
than 2 days to show up as new throughout the system. It would
be too bad if both calendar and bboard had their own way of
thinking about what constitutes new data.
As for whether older packages will be retro-fitted, I'm guessing
that will happen on an as-needed basis. You can bet that the
new forums package I'm working on will use this preference
package. I'm hoping others can help moving other packages to
this framework, whenever it makes sense.
