On 11/08/2011 11:09 AM, Zane Bitter wrote:
On 08/11/11 16:52, Roman Rakus wrote:
> On 11/08/2011 11:23 AM, Radek Novacek wrote:
>> Both run_uri and run_string commands should return string in this format:
>> OK\n<data>
>> or
>> FAILED\n<code>\n<data>
>>
>> Where<data> is arbitrary optional data per backend and<code>
is
>> error code from the backend.
> Wouldn't it be better to return some kind of struct? String isn't good
> to handle multiple various data types.
>
> Something like:
> {
> int code // 0 = ok,>1 failed
> string data
> }
>
> Is it possible?
QMF supports multiple return values ("output arguments"), so in that
sense it is possible. Not sure about DBus?
I like this idea, and the current format is more a legacy of how our
ideas about the API have evolved than anything else. In the short term
I'd still like to see this patch go in to harmonise run_uri with
run_string, but this seems like a good direction to move in.
Yes, I agree with the ACK on this patch.
Long term I also agree that more structured return value would be nice.
However, we have backwards compatibility to consider now that this API
is already going into a release of both RHEL and Fedora. We're kind of
stuck with it.
We have some options, it's just not as pretty. We could add new APIs
that return results in a different way. We could add another parameter
that requests that results be provided in a different way. It's safe to
call a QMF method without an argument, as long as the agent is written
not to expect it.
--
Russell Bryant