[cvs] [Wiki] changed: Project/HordePolicy

[Chuck Hagenbuch]

chuck  Tue, 30 Sep 2008 16:59:38 -0400

Modified page: http://wiki.horde.org/Project/HordePolicy
New Revision:  1.28
Change log:  start updating/refining spec and goals

@@ -2,8 +2,22 @@

  + Horde Policies

  The idea of Horde Policy is to implement a replacement for the  
current prefs system, modeled after how Group Policy Objects work in a  
Microsoft Active Directory.  Including a nice administrative GUI,  
meaning no more editing prefs.php files, and happier admins.
+
+
+++ Goals
+
+The Horde_Policy system should be able to replace all user  
preferences and most admin/file-level configuration. Policies should  
be nestable; it should be possible to load policies based on arbitrary  
criteria such as time of day, server load, user group, IP address,  
etc; administrators should be able to define at each level of the  
policy tree whether a value can be overridden. End users would only  
see the values that could be overridden, but should still be able to  
create multiple policies (probably not nested, though, for simplicity)  
that could be switched between, like "Locations" in some systems or  
separate "Home" and "Work" profiles (or probably more useful, Desktop  
and Mobile browser profiles).
+
+From a system standpoint there should be three kinds of policies: PHP  
files on disk that can contain arbitrary logic (obviously admin only),  
YAML or JSON files on disk that contain a list of keys and values plus  
metadata (overridable or not, but no conditions), or policies stored  
in a SQL database or other backend storage, which would be  
functionally equivalent to on-disk JSON/YAML files.
+
+When the policy system is fully implemented, the only classic  
configuration necessary should be enough information to point to the  
root policy. This could be as simple as the location of the root .php  
file that loads all other policies (though other policies might not be  
required), which would essentially eliminate ALL other configuration.
+
+To avoid having a huge tree in memory, policies will be split out on  
a system level, such as main config, main preferences, mime driver  
configuration, etc. Applications will be able to either override  
system values or add their own keys, like they currently can, so that  
the Policy system will automatically reconcile IMP-specific MIME  
settings when in IMP's context.
+
+From an end-user perspective, though, there should be one policy (or  
two, if they have Home and Work policies), with tabs/sub-sections for  
apps and section settings.
+

  ----

  ++ Visualization of a Horde Policy