perfsonar development work

[Szymon Trocha <>]

Maciej, Martin,

Maciej Glowiak wrote:

> 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:

Do we have an agreement here? I didn't see any objections.

> 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) ?

Martin - will you be able to take this action while Maciej does the two 
others?

> 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)

Any opinion on this from other developers?

Regards,
--
Szymon Trocha

Poznan Supercomputing & Ntw. Center ::: NETWORK OPERATION CENTER
Tel. (+48 61) 8582022
http://noc.man.poznan.pl  ::: http://noc.pionier.gov.pl