[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