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
+
--
commits mailing list
Frequently Asked Questions: http://wiki.horde.org/FAQ
To unsubscribe, mail: [email protected]
