\documentclass{article} \usepackage{ulem} \usepackage{graphicx} \usepackage{hyperref} \pagestyle{headings} \begin{document} \part{Horde 6 TODO List} \section{Confirmed} \begin{itemize} \item Git reorganization \begin{itemize} \item Packagist packages for libraries \item Command to automatically split current framework library from git repo at framework/bin/horde-git-split \end{itemize} \item Refactor Horde\_Registry bootstrapping for actions where authentication is not known at beginning of process (AJAX endpoint; RPC) \item Use Horde\_Registry\_Logout to register logout actions; remove Application level logout() \item Cleanup Exception handling \begin{itemize} \item All Horde code/libraries should use \$logged parameter of Horde\_Exception \end{itemize} \item Remove External session handler from horde/conf.php \begin{itemize} \item This can be accomplished by creating a SessionHandler class and passing in this classname to 'type'. \end{itemize} \item Translations \begin{itemize} \item Horde\_Translation: Vastly simplify framework library implementation by using late static binding - should only need to declare the path to the base of the application in a member variable. \item Use Horde\_Translation instead of \_() in Horde base application \item Remove outdate, unmaintained translations \end{itemize} \item Fix inconsistent usage of Hashtable and HashTable \item Horde\_Compress \begin{itemize} \item Move TNEF code out of the Compress library (can still wrap the Horde\_Compress::decompress() call to use Horde\_Tnef). \item Needed to simplify the code-base, and to enable a very basic TNEF writer (so we can send iTip replies that MS-Outlook can work with natively). \end{itemize} \item Horde\_ActiveSync \item Various major refactoring tasks (see the library's TODO file). \item Horde\_Kolab\_Storage \begin{itemize} \item General package cleanup. \item Remove support for non-maintained Pear/Cclient/Rcube drivers. \end{itemize} \end{itemize} \section{To Discuss} \begin{itemize} \item Cleanup Exception handling \begin{itemize} \item Remove Horde\_Exception\_Wrapped \item Provide separate error message for admins vs. error message meant for end user display \end{itemize} \item New Hooks format \begin{itemize} \item 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. \end{itemize} \item Centralized GC \begin{itemize} \item 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. \end{itemize} \item Websockets version of AJAX endpoint \item AJAX framework improvements \begin{itemize} \item Remove "Handlers". Replace with a separate file/object for each action. Allows more granular support re: permissions/read-only \item Provide a way (callback?) to alter the JSON output at send-time \end{itemize} \item Log improvements \begin{itemize} \item Ability to queue log entries (configurable), for logging after request. \item 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. \end{itemize} \item Application API access \begin{itemize} \item 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 \begin{itemize} \item One solution: Have these calls return an object that will allow to gracefully degrade if advanced object support is not available \item 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). \end{itemize} \end{itemize} \item Require PHP 5.4 (or 5.5?) \begin{itemize} \item 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. \end{itemize} \item Simplify views \begin{itemize} \item Should only be "Standard" and "Mobile". \begin{itemize} \item Standard is either the current dynamic view (if exists) or the current basic view \item Mobile is the jquery mobile based view
[/listitem]- Automated CHANGES generation \end{itemize} \item It is difficult enough to keep changelogs sync'd between branches (release <-> master). We should really be using package.xml only and then having CHANGES being automatically generated at release time. \begin{itemize} \item If argument is "then people can't tell what has changed since last release", this is not sufficient reasoning. We can easily point them to a github page showing all commit changes (git log xyz..) since previous release.[/list][/listitem]- Change motd.php configuration \end{itemize} \item 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.[/list] \end{itemize} \end{itemize} \section{Vague ideas} Optional 2 factor auth (TOTP) \begin{itemize} \item 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) \item Still toying OpenId Connect both as consumer and provider. \item 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) \item Auth\_Fallback driver for supporting multiple backends at once. \begin{itemize} \item maybe stackable, but more than 2 backends looks exotic \item maybe extend to migrate-on-login scenarios \end{itemize} \item 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 \begin{itemize} \item with inherent support for permissions, alternate/no auth, rate limiting, logging \item make it easy to wrap internal inter-app api \item avoid per-backend extra metadata if possible \item look into what it takes for limited api versioning \item support for delayed/enqueued processing of long-running tasks \item implement most fundamental horde entities for bootstrapping though api : perms, users, groups, locks, api introspection, \item not necessarily H6 - maybe move to separate page -> Ralf \end{itemize} \end{itemize} \end{document}