This would imply that those services know about the storage backend 
being used. Because if not using a splitread environment, not being 
able to access the data still has to be fatal error. And due to 
abstraction reasons those services obviously don't know about their 
storage backends, let alone the concreted Horde_Db backend.

I know that horde updates some prefs like login time,
so in read-only mode there would be some functionality
los.  So we should notify the user about this, but i think the
functionality is small compared  with the possible downtime
of the whole system, unless I am missing an important feature.

Possible functionality  los:



Creating/Changing Shares ->  notify the user that the action failed
Changing Persission           ->  notify the user that the action failed
Creating/Changing Objects ->  notify the user that the action failed

updated Login Time and IP  -> Unauthorised access may not be noticed.
changes in prefs                    -> Change the setting only in the 
cache, notify the
                                                        user that the 
change is not saved.
ActiveSync/SyncML                 -> Will fail.
imp_history                              -> There will be a los of 
history for mails send,
                                                         replyed or 
forwarded, outgoing mail limitation
                                                         will not 
work, so there could be an option to
                                                        disallow sending mails

What should still work.

Read mails, create mail folders, move mails,  read access on shares 
and shared objects,


Some possible scenarios:

1. HA/LB: 2 Horde Server Active/Active and 2 databases in 
Active/Passive setup at two locations.
                   If the first location (with the active) database 
can't be reached by the second location it is
                   quit hard to automatic tell if the systems or only 
the network is down. Switching to read-only
                   on the second location would allow an admin to 
decide whats the case while his user at the
                   second location still could be used

2. Migration: Database Migration can take quite some time (Horde 3 -> 
Horde 5 more than 8h)
                  Allowing the users read only access to the old 
system, while the database is updated
                 on a new  system.

I wonder if this is really useful, because there is almost always some 
write query during a user session. Be it the logging of the login time 
to the preferences or setting default preference for which calendars 
to display etc.

if the connection to the write database fails don't bail out with an 
exception.
Insted show a warning notification but let the user use horde and the 
other horde apps
as far as possible without writing to the database, (read kalendar, 
addressbooks, notes ...)
read / write mails