[dev] Api consistency for share listing

Michael J.Rubinsky mrubinsk at horde.org
Sat Dec 4 17:32:31 UTC 2010


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]()?


--mike

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


More information about the dev mailing list