Horde 6 TODO List

Confirmed

• Git reorganization
  • Packagist packages for libraries
    • Command to automatically split current framework library from git repo at framework/bin/horde-git-split
• Refactor Horde_Registry bootstrapping for actions where authentication is not known at beginning of process (AJAX endpoint; RPC)
• Use Horde_Registry_Logout to register logout actions; remove Application level logout()
• Cleanup Exception handling
  • All Horde code/libraries should use $logged parameter of Horde_Exception
• Remove External session handler from horde/conf.php
  • This can be accomplished by creating a SessionHandler class and passing in this classname to 'type'.
• Translations
  • 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.
    • Use Horde_Translation instead of _() in Horde base application
    • Remove outdate, unmaintained translations
• Fix inconsistent usage of Hashtable and HashTable
• Horde_Compress
  • Move TNEF code out of the Compress library (can still wrap the Horde_Compress::decompress() call to use Horde_Tnef).
    • 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).
• Horde_ActiveSync
  • Various major refactoring tasks (see the library's TODO file).
• Horde_Kolab_Storage
  • General package cleanup.
    • Remove support for non-maintained Pear/Cclient/Rcube drivers.

To Discuss

• 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 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
  • Remove "Handlers". Replace with a separate file/object for each action. Allows more granular support re: permissions/read-only
    • Provide a way (callback?) to alter the JSON output at send-time
• 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).
  • 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
• Automated CHANGES generation
  • 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.
    • 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.
• Change motd.php configuration
  • 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.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