perfsonar development work

[Jason Zurawski <>]

Maciej, Martin & All;


> 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 take it 'description' deals with more of a textual description of the 
actual error message we are reporting?  I agree there needs to be 
another field (such as 'stack-trace') but it should have a general name 
that can be used for other things as well such as 'content' or simply 
'value'.


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


I don't like the idea of repeating information across multiple tags.  If 
the URI for 'type' were to have the error level built into it, we would 
not need a level tag at all.  Also, couldn't a single message exist in 
many levels (i.e. debug vs info level for a certain error depending on 
severity)?  I would propose we keep Martin's structure the same as it 
better reflects the logging infrastructure as used by the services. 


-jason