[dev] API Interface Rewrite

[Chuck Hagenbuch]

Quoting Michael M Slusarz <slusarz at horde.org>:

> [Add a couple of more ideas that came to me right after I sent the message]
>
> Quoting Michael M Slusarz <slusarz at horde.org>:
>
>> My initial thought (pseudocode version) is this:
>>
>> // Rename files to lib/Api.php so they are autoloadable.
>> class App_Api
>> {
>>    // Does this application support a mobile view?
>>    public $mobileview = [boolean];
>>
>>    // The version of the application (gets rid of version.php files)
>>    public $version = [string];
>>
>>    // The existing services array
>>    protected $_services = array();
>>
>>    public function [API name - no more '_app_' prefix] ()
>>    {
>>    }
>>
>>    ...
>>
>>    // Reserved function: returns permissions info. Need to return  
>> in a function since data may include
>>    // gettext strings, which can not be defined in class variables.
>>    public function perms()
>>    {
>>        return array();
>>    }
>>
>>    // Reserved function: returns the Horde_Menu object to display.   
>> Used, for example, in Prefs UI output.
>>    public function getMenu()
>>    {
>>        return new Horde_Menu();
>>    }
>>
>>    // Prefs UI stuff: Do we want to move code from lib/prefs.php  
>> file into the API file?
>> }

I think what you are describing is a Horde_Application_Base class - a  
base for what makes a Horde application a Horde application. I don't  
think this is the same thing as most of the current registry API  
methods; I think those would go in a Horde_Application_Api tree instead.

Basically I see a difference between things that assume a Horde  
application, in Horde context (like prefs callback, mobile view, menu  
(which I'd replace with a view, but, baby steps)), and with an  
external API that an app defines.

-chuck