perfsonar development work

[Maciej Glowiak <>]

------------------------------------------------------------------------
  <nmwg:metadata id="result-code1">
    <nmwg:subject id="reference-to-metadata"
      metadataIdRef="metadata_X"/>
    <nmwg:eventType>http://ogf.org/ns/nmwg/result/2.0/</nmwg:eventType>
  </nmwg:metadata>

  <nmwg:data id="result-code-description1"
    metadataIdRef="result-code1">
    <nmwgr:datum>
      <type>http://perfsonar.net/common/storage/xmldb/wrong_query</type>
      <level>ERROR</level>
      <description>blah, blah.</description>
    </nmwgr:datum>
  </nmwg:data>
------------------------------------------------------------------------

Martin Swany wrote:
> Hi all,
> As discussed at the meeting in Brasil, the format of
> perfSONAR result codes needs some refinement.
>
> Based on email input and discussion at the meeting,
> we proposed something that looks like the attached
> file.
>
> The key things to note about this are that the result
> code datum looks a lot like either a syslog message
> or a Log4J message.  Also, the type is a fully qualified
> URI from the perfSONAR namespace.  This namespace
> can be managed on the Wiki.
>
> Please take a look and send comments to the list.

Hi Martin,

The proposal is fine for me. I'd consider using <stack-trace> tag as an 
optional parameter for stack trace of error/exception (useful for 
developers) next to <description> tag (which will contain just a textual 
description).

I can see your proposal is just a refinement of the structure or result 
codes. However, one change - adding <level> parameter would need change 
in pS base code (as well as services). Of course it may be done 
automatically, but it'd need a list (hierarchy) of result codes URLs 
(such as http://perfsonar.net/common/storage/xmldb/wrong_query )

Perhaps we should consider using for instance:

http://perfsonar.net/error/common/storage/xmldb/wrong_query
http://perfsonar.net/success/common/get/consensus

for <type> tag. Then ERROR, SUCCESS (or even WARNING) could be genereate 
automatically without any changes in pS-base PerfSONARException 
structure which handles result codes.

Also, all result codes in all services would need to be changed (in 
order to apply them to the new hierarchy).

So I see three major areas of change if we agree to change the structure:

1a) re-define hierarchy of result codes (define URL-like codes for all 
existing result codes) - on page:

   http://wiki.perfsonar.net/jra1-wiki/index.php/Result_code_hierarchy

1b) change result codes in all servicess according to 1a)

2) changes in pS-base (mostly PerfSONARException to generate new 
structure - AFAIR)

I can do 2) if necessary and partially 1b) for LS (other developers for 
other services). Martin, would you take 1a) ?

Anyway, there is still pending question whether we want to support 
"stack" of result codes. AFAIR we discussed it during "result codes" 
discussion (Ann Arbor meeting?), but we decided not to follow that 
direction. But maybe that's a good time for just defining theoretical 
way of handling that (without implementing it now - maybe in the future)

Best regards

Maciej

--

 --------------------------------------------------------------------
| Maciej Glowiak        Network Research and Development            ||
| 

     Poznan Supercomputing and Networking Center ||
| (+48 61) 858 2024          -- skype_id: maciej_psnc   GG: 4526858 ||
 ====================================================================