[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 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.
>
> Just like any API call, or what do you mean?

Yes, the application is on the stack *during* the listShares() call,  
but in the client code, you now have a collection of, e.g.  
Ansel_Gallery objects. Calling methods on those objects from client  
code could potentially be problematic.

--mike

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