[dev] Api consistency for share listing

[Michael J.Rubinsky]

Quoting Jan Schneider <jan at horde.org>:

> Zitat von "Michael J.Rubinsky" <mrubinsk at horde.org>:
>
>>
>> Quoting Jan Schneider <jan at horde.org>:
>>
>>> Zitat von "Michael J.Rubinsky" <mrubinsk at horde.org>:
>>>
>>>>
>>>> Quoting Alfonso Marín Marín <almarin at um.es>:
>>>>
>>>>> Hello,
>>>>>
>>>>> Cheking module APIs, i have noticed that listCalendars in  
>>>>> kronolith return an array of ID's, but listTasklists in nag and  
>>>>> listNotepads in mnemo return the datatree objects instead the  
>>>>> ID's.
>>>>>
>>>>> ¿Is it any reason to do that? I think all of then should behave  
>>>>> like listCalendars
>>>>
>>>> Agreed. Can you create a ticket on bugs.horde.org so it doesn't  
>>>> get forgotten about?
>>>
>>> We should probably have both: a generic listShares() method in all  
>>> apps that support shares, and (still consistent)  
>>> listCalendars/Tasklists/Etc() methods for the specific applications.
>>
>> What would the difference(s) be between these two? If it is that  
>> one method returns the actual share object, is that something we  
>> really want to do via the API? Having an application-level object  
>> be returned via the API doesn't make much sense to me.   
>> Alternatively, if we want the information available in the share  
>> object, we could return some sort of array/hash/json/whatever  
>> representation of the object properties, not the object itself.
>>
>> Or, are you just suggesting that we have a listShares() method that  
>> is just an alias of list[Calendars|Tasklist]()?
>
> No, I indeed want listShares() to return the shares. It doesn't  
> matter if they contain application-specific information,

It's not so much the information I'm concerned about, but the fact  
that some of the methods may rely on the application being  
active/pushed on the top of the registry stack.

as


--mike

The Horde Project
http://www.horde.org