[dev] Re: [imp] imp 2.3.x vs TWIG

[Chuck Hagenbuch]

Quoting Jon Parise <jon@csh.rit.edu>:

> > Just one thing I wasn't sure about - is it possible to have _some_
> > preferences only stored in the Session, and other ones in the DB?
> 
> No, it isn't, but that's not a bad idea.

This seems like it could get messy... right now, that more or less describes 
things that are defined in config/servers.php...

> > I'd like hard storage for most stuff except for the server/port/protocol
> > etc, but couldn't immediately see how.

Why not... ah. Hmm. Can't lock the prefs while still letting the users change 
them. I see the problem...

I still think the solution is to have new login values override preferences, or 
something, somehow... (yeah, it's about time for bed. articulateness is fading).

> 1)  Introduce session-level caching in the Prefs.php parent class that
>     will cut down on excessive "read" operations.  This is fairly
>     trivial overall, but it will still take me a while to make sure I
>     have everything working both correctly and optimally.

Great.

> 2)  Add a "mapping" layer to the preferences code.  This would work
>     similarly to Turba's source attributes mapping.  For example, when
>     using LDAP preferences, a user may already have a fullname or
>     email address attribute set.  There's no need for us to store our
>     values separately and redundantly (well, that's up to the local
>     administrator, but still...).
>
> 3)  Expand the "mapping" layer to allow multiple preferences sources
>     to be used for a given session.  This would allow the behavior you
>     suggest where some preferences could be stored in LDAP (i.e. the
>     user's personal information), some preferences could be stored in
>     an SQL database (i.e. the user's filters and navigator preferences),
>     and some information could be stored in the session (i.e. the
>     current sorting values).

I can see the usefulness of these, but I am worried about the introduced 
complexity...

> Note that a lot of these capabilities have numerous advantages beyond
> the IMP application, too.  Other Horde apps could really benefit from
> these "mappings".  They'd be able to read IMP's preferences a lot more
> easily, for example.

That's a very good point... we should probably think about some preferences 
(like 'fullname') that should be explicitly Horde-wide, and not owned by any 
one user...

-chuck

--
Charles Hagenbuch, <chuck@horde.org>
Entropy. It's what's for dinner.