Tickets :: Comment on [#12740] Implement API for non-RPC friendly API calls.

* Your Email Address
* Spam protection	Enter the letters below: .__ .__..__ .__ . , [__)\| \|[__)[__) \./ \| \|__\|\| \| \|
Comment	>>> 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.
Attachment
Watch this ticket

Saved Queries