[#12740] Implement API for non-RPC friendly API calls.
Summary Implement API for non-RPC friendly API calls.
Queue Horde Base
Queue Version Git master
Type Enhancement
State Accepted
Priority 1. Low
Owners
Requester slusarz@horde.org
Created 2013-10-07 (2903 days ago)
Due
Updated 2013-11-23 (2856 days ago)
Assigned
Resolved
Milestone 6
Patch No

Comments
Michael Slusarz <slusarz@horde.org> 2013-10-07 02:38:02
Should probably return some kind of object, so that we can do things 
like data conversion from backend transparently from the calling code 
(i.e. photo information is returned in a specific array-hierarchy that 
is documented nowhere).

Michael Rubinsky <mrubinsk@horde.org> 2013-10-07 14:18:19
Anything returned from the API should be compatible with a RPC call as 
well. Requiring logic in the returned object to access the requested 
data will not work over e.g., json-rpc calls.

Jan Schneider <jan@horde.org> 2013-10-07 15:25:18
Correct

Michael Slusarz <slusarz@horde.org> 2013-10-07 18:09:09
> Anything returned from the API should be compatible with a RPC call 
> as well. Requiring logic in the returned object to access the 
> requested data will not work over e.g., json-rpc calls.

Huh?  How is this supposed to work?  See mail/imapOb - that returns a 
Horde_Imap_Client_Base object.  That is most certainly NOT something 
that can be returned via a JSON-RPC call.  (or mail/flagList.  Or 
mail/createMailbox).

And that is extremely concerning if you are saying that 
inter-application API calls are restricted to simple data structures . 
  That is a **crippling** limitation for a feature that came AFTER the 
original API design - which allowed PHP objects to be returned.

If you disgaree, than there needs to be a separate RPC framework in 
the future.  Or at least a separate search call that is RPC specific.

But you absolutely cannot be expected to know the structure of the 
photo data object, so at a minimum this ticket cannot be closed.  This 
needs to be documented somewhere.

Jan Schneider <jan@horde.org> 2013-10-14 13:01:04
>> Anything returned from the API should be compatible with a RPC call
>> as well. Requiring logic in the returned object to access the
>> requested data will not work over e.g., json-rpc calls.
>
> Huh?  How is this supposed to work?  See mail/imapOb - that returns 
> a Horde_Imap_Client_Base object.  That is most certainly NOT 
> something that can be returned via a JSON-RPC call.  (or 
> mail/flagList.  Or mail/createMailbox).

Well, just because you added API methods in the past that return 
objects, doesn't mean that this is correct behavior.
The point is that all API methods are exposed through the external API 
too. This indeed renders all methods that return or expect objects in 
an RPC context useless. For methods like imapOb this might be 
acceptable because using it only makes sense in a PHP context anyway.
That's a completely different story for methods like contacts/search 
though, which make a lot of sense in an RPC environment.

> And that is extremely concerning if you are saying that 
> inter-application API calls are restricted to simple data structures 
> .  That is a **crippling** limitation for a feature that came AFTER 
> the original API design - which allowed PHP objects to be returned.

Wrong. The original API design always only allowed simple structures. 
There might have been an exceptions somewhere, or two, but the methods 
that you used an argument for your point of view have been added by 
yourself, long after APIs have been added or used in Horde.

> If you disgaree, than there needs to be a separate RPC framework in 
> the future.  Or at least a separate search call that is RPC specific.
>
> But you absolutely cannot be expected to know the structure of the 
> photo data object, so at a minimum this ticket cannot be closed.   
> This needs to be documented somewhere.

Agreed, but it's the job of the API method, or at least for Turba 
internally, to convert these kind of attributes to something usable.

Michael Rubinsky <mrubinsk@horde.org> 2013-11-23 18:23:53
Moving this to the general horde queue, and changing title to reflect 
the underlying issue.