Re: pvAccess Status returns

[Matej S. <mat...@co...>]

The idea about current Status is that no hardcoded definitions are
needed (no need to sync client/server).
The thing V3 does not do well is that CA Status error codes. They are
fixed and usually you get generic error code back, e.g. PUT_FAILED,
i.e. no stack trace, etc.

However, current definition is "human oriented". The code cannot do
any decision on return status (parsing a string in not a good way to
do it). If we want this, we need to add "int code" field. But then we
need to define some error codes (hmmmmm).
"int code" should not imply the message, message is there to tell
something more.

Matej

On Tue, Dec 17, 2013 at 10:08 AM, Ralph Lange <Ral...@gm...> wrote:
> Hi Greg,
>
> You don't even have to go that far:
> What if - when writing a complex structure - some elements fail the
> operation while the others succeed?
>
> Very similar (if not same) thing.
>
> Cheers,
> ~Ralph
>
>
> On 16.12.2013 23:34, White, Greg wrote:
>> Hi Ralph,
>>
>> Also, we're going to need to be able to indicate the success or failure of a
>> collective operation soon, aren't we? Did you have a plan for that?
>>
>> For example, how to indicate success or failure of one or two gets or puts
>> among many in a dbGroup operation. For instance, how will you say "couldn't
>> get CA channels mirrorpos3, mirrorpos4, mirrorpos7 in group operation for PVA
>> PV allmirrorpos" while correctly returning mirror1pos, mirror2pos, mirror5pos,
>> mirror6pos. At SLAC we do that by returning an array of status. But that makes it
>> hard to quickly evaluate total success. An accompanying bitfield may be good.
>>
>> Cheers
>> Greg
>>
>> On Dec 15, 2013, at 8:29 PM, Greg White <gr...@sl...> wrote:
>>
>>> Hi Ralph,
>>>
>>> Yes. Let's take it further though and really have a standard for status
>>> indication that covers message codes (status) and string messages.
>>> For instance:
>>> - What severity are the status codes. Is 0 the only ok condition and
>>>> 0 all the same severity (uni), or should there be more structure than that
>>> (eg Fortran).
>>> - What's the association between message code and message if any. Eg Should
>>> status code == 34 always be "illegal argument", or is only the code standardized.
>>> - May the strings take format indicators, so one can add arguments. Eg
>>> "Illegal argument value '%s' supplied for argument '%s'".
>>> - Standard for message format. I very much want to see proper use of
>>> quotations, so people know what is the thing that was illegal.
>>> - Externalization of strings, so installations can override, or translate.
>>>
>>> Do you want to take charge of development guidelines?
>>>
>>> For the scientific V4 services I did here, I developed my own standard for
>>> stacking and concatenating exception messages, separated by semi-colons, so
>>> the end result that as user sees is always a meaningful error. Eg "Unable to
>>> get twiss parameters of 'QUAD:LTU1:880'; no GOLD model data found for in
>>> database for mode '5'", where 5 was a user supplied parameter.
>>>
>>> Cheers
>>> Greg
>>>
>>>
>>> On Dec 14, 2013, at 6:58 AM, Ralph Lange <Ral...@gm...> wrote:
>>>
>>>> Hi,
>>>>
>>>> As far as I see, we defined the Status return for a single pvAccess
>>>> operation as a numerical severity plus string plus more data (stack
>>>> trace etc.)
>>>>
>>>> I think in this case we need a catalog of standard strings for certain
>>>> cases (extended as more cases appear), else clients will never be able
>>>> to properly react to certain standard status returns. (Errors like
>>>> "insufficient privilege", "illegal value", or warnings like "numerical
>>>> value was limited", "string was truncated" etc.)
>>>>
>>>> Maybe this would be easier using an enum (maybe additional)? Usually
>>>> APIs have enums at this point, and I am quite surprised that we have
>>>> only a free form text. Are clients supposed to do regexp-based guessing?
>>>> (So that they stop working in a different language environment?)
>>>>
>>>> Cheers,
>>>> ~Ralph
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Rapidly troubleshoot problems before they affect your business. Most IT
>>>> organizations don't have a clear picture of how application performance
>>>> affects their revenue. With AppDynamics, you get 100% visibility into your
>>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk