| Summary | failover mode for preferences |
| Queue | Horde Base |
| Queue Version | HEAD |
| Type | Enhancement |
| State | Resolved |
| Priority | 1. Low |
| Owners | |
| Requester | liamr (at) umich (dot) edu |
| Created | 07/13/2005 (7321 days ago) |
| Due | |
| Updated | 11/23/2006 (6823 days ago) |
| Assigned | 10/24/2005 (7218 days ago) |
| Resolved | 11/23/2006 (6823 days ago) |
| Milestone | |
| Patch | No |
Summary ⇒ failover mode for preferences
State ⇒ Resolved
so I'm resolving the ticket. I see a number of problems with falling
back to local sessions:
- The user will be confused by the notice - they don't know/care what
the session handler is (I know, just don't issue the notice, this
isn't the only thing).
- People use db-backed sessions for a reason - usually with clusters,
where file-based sessions would result in random logouts as the user
eventually hits a different webserver. I don't think that'd be an
improvement.
State ⇒ Accepted
State ⇒ Assigned
Priority ⇒ 1. Low
Type ⇒ Enhancement
Summary ⇒ failover mode for preference and sessions
Queue ⇒ Horde Base
State ⇒ New
the default file based session handler, and preference drivers to fall
back to "none" or "php sessions" if connections to custom drivers fail.
Say you're using a DB server for prefs, and it becomes unavailable.
Rather than say "There was a problem contacting the DB server", and
preventing it fails back to built-in php methods and says something
like "There was a problem contacting the preferences database. You
will be using default prefereces for the duration of this session".
Similarly, if you're using a SQL based session, if it can't connect to
the sessionhandler, rather than preventing the user from using the
application, how about throwing up a notice saying that it's using the
default session handler, and then continuing?