Skip to Content.
Sympa Menu

perfsonar-dev - Re: [pS-dev] Proposal for Result Code formatting

Subject: perfsonar development work

List archive

Re: [pS-dev] Proposal for Result Code formatting


Chronological Thread 
  • From: Maciej Glowiak <>
  • To:
  • Cc: Martin Swany <>, , Szymon Trocha <>, Eric Boyd <>
  • Subject: Re: [pS-dev] Proposal for Result Code formatting
  • Date: Mon, 13 Aug 2007 11:29:39 +0200

Hi Jason,

Jason Zurawski wrote:
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'.

Using general name is okay for me. From those two names I prefer 'content'. Or maybe 'details'?

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.

I thought about required changes in perfSONAR-base and java services code. But, finally, all java code where result codes are thrown will need to be changed.

We should start (after an agreement) from translating existing result codes into new URL-based hierarchy

Maciej


--

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

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





Archive powered by MHonArc 2.6.16.

Top of Page