[commits] [Wiki] changed: Project/H6TODO

[Wiki Guest]

guest [87.171.162.219]  Fri, 30 Dec 2016 21:04:58 +0000

Modified page: https://wiki.horde.org/Project/H6TODO
New Revision:  22
Change log:  Can't get this out of my head

@@ -32,9 +32,9 @@
  * Cleanup Exception handling
    * Remove Horde_Exception_Wrapped
    * Provide separate error message for admins vs. error message  
meant for end user display
  * New Hooks format
-  * Have config file be a class that extends/implements a base Horde  
class/interface.  All hooks can be defined without having to comment  
them out - active hooks would then be defined in a public variable  
config array.  Another idea: hooks live in a separate subfolder ...  
one hook per file.  hooks.php has name of class to load.
+  * Have hook config file be a class that extends/implements a base  
Horde class/interface.  All hooks can be defined without having to  
comment them out - active hooks would then be defined in a public  
variable config array.  Another idea: hooks live in a separate  
subfolder ... one hook per file.  hooks.php has name of class to load.
  * Centralized GC
    *  Want to add a global Horde GC system. Libraries implement GC  
class, and when triggered we don't immediately do GC but instead send  
GC requests to a queue. Then we either do ALL GC requests on a random  
access (i.e. logout access; this doesn't require any admin setup) or  
admin would have option to run cron process to periodically handle GC  
queue.
  * Websockets version of AJAX endpoint
  * AJAX framework improvements
@@ -46,9 +46,11 @@
  * Application API access
    * Current status is apparently that complex objects are not  
allowed as return from API calls due to possibility that they may be  
returned via RPC.  But we have a bunch of code that does do this, and  
the takeaway is that inter-application sharing is much much more  
important than remote calls
      * One solution: Have these calls return an object that will  
allow to gracefully degrade if advanced object support is not available
      * Or else figure out way to consistently determine how to  
document calls not intended for remote access.  I see absolutely  
nothing wrong with allowing access to inter-application calls via  
native PHP interface without allowing remote call.  (Logistically,  
this could be done by defining yet another API for applications.  But  
practically, this is better done within the existing framework to  
minimize complexity).
-* Require PHP 5.4 (or 5.5?)
+
+* Require PHP 5.4 (or 5.5?)
+ * I would vote to define a PHP feature set you would not want to do  
without and then decide. All pre-7 looks fine from admin perspective  
by today.
  * Simplify views
    * Should only be "Standard" and "Mobile".
      * Standard is either the current dynamic view (if exists) or the  
current basic view
      * Mobile is the jquery mobile based view
@@ -59,7 +61,22 @@
    * @@---This file seems to make more sense by displaying whatever  
is output by that file, vs. having to use ob buffer magic to capture a  
string into a PHP variable.@@ This is on purpose to allow overriding  
of output with the .local.php mechanism.

  ++ Vague ideas
  Optional 2 factor auth (TOTP)
-* B1 will probably generate a h5.2-compatible "totp-auth" app+library  
which can later be integrated into the h6 auth library+support code
+* B1 will probably generate a h5.next-compatible "totp-auth"  
app+library which can later be integrated into the h6 auth  
library+support code (as of end 2016, it is still planned but no  
schedule is set)
+* Still toying OpenId Connect both as consumer and provider.
+
  * API versioning for RPC api  (If it is split from the internal  
registry->call api as discussed above - otherwise this can easily be  
faked by adding parameters to the passed options array)
+* Auth_Fallback driver for supporting multiple backends at once.
+  * maybe stackable, but more than 2 backends looks exotic
+  * maybe extend to migrate-on-login scenarios
+
+* Add a new structure to Horde_Rpc to handle Rest, Dav and existing  
Rpc backends (json, xml-rpc, other) without breaking existing  
interfaces, at least for now
+  * with inherent support for permissions, alternate/no auth, rate  
limiting, logging
+  * make it easy to wrap internal inter-app api
+  * avoid per-backend extra metadata if possible
+  * look into what it takes for limited api versioning
+  * support for delayed/enqueued processing of long-running tasks
+  * implement most fundamental horde entities for bootstrapping  
though api : perms, users, groups, locks, api introspection,
+  * not necessarily H6 - maybe move to separate page -> Ralf
+