[[toc]]
+ Horde 6 TODO List
++ Confirmed
* Git reorganization
* Packagist packages for libraries
* Refactor Horde_Registry bootstrapping for actions where authentication is not known at beginning of process (AJAX endpoint; RPC)
* Cleanup Exception handling
* All Horde code/libraries should use $logged parameter of Horde_Exception
* Remove Horde_Exception_Wrapped
* (Discuss) Provide separate error message for admins vs. error message meant for end user display
* Remove External session handler from horde/conf.php
* This can be accomplished by creating a SessionHandler class and passing in this classname to 'type'.
++ To Discuss
* 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.
* 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
* Log improvements
* Ability to queue log entries (configurable), for logging after request.
* Also... right now, we need to fully process log entry before we know if we are going to accept, since log level checking happens at the lowest levels of logging chain. Need to move this up in chain so that we can exit out of log code earlier if we know that we don't want to process.
* 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).