Result codes in MDM RRD MA and LS - action from last conf call
Hi, I've attached the lists of result codes which are used in java mdm services (RRD MA and LS). (Slawek and Piotr, thanks that you had some time to collect them) Cheers, Roman
Hi Roman/All; I have added these, and the pSPS result codes that Aaron prepared to the wiki for the call on Thursday. Some comments on yours: RRDMA: - Are these only for the perfSONAR layer, or do these cover other exceptions that may come up from tomcat/axis/exist? - I only see one that uses the 'error.' format: "error.common.storage.xmldb.open". Are these all 'error's or are some of them 'success' too? - There is a lot of reuse of 'query_exception'. In the new model would that still be the case or would there be more specific new error codes used? LS: - I see more use of 'success.' and 'error.' here, which is very different than in the RRDMA. - The LS messages are also very specific compared with the RRDMA. Will some of the LS operations be generalized when the new format is adopted, or will they continue to be very specific? Thanks; -jason On 4/28/10 6:42 AM, Roman Lapacz wrote:
Hi,
I've attached the lists of result codes which are used in java mdm services (RRD MA and LS).
(Slawek and Piotr, thanks that you had some time to collect them)
Cheers, Roman
Hi Jason! Jason Zurawski wrote:
RRDMA:
- Are these only for the perfSONAR layer, or do these cover other exceptions that may come up from tomcat/axis/exist?
Those result codes, which were sent present only perfSONAR layer. If some exception comes from eXist it is covered by perfSONAR code. However presented list doesn't cover tomcat and axis errors if they appear besides the perfSONAR code and cannot be catch by it.
- I only see one that uses the 'error.' format: "error.common.storage.xmldb.open". Are these all 'error's or are some of them 'success' too?
Success is only responded by echo request and has a url format. When other requests are completed successfully just a proper message with requested data is sent without any success code and I suppose it is compatible with nmc-wg standard for MA services.
- There is a lot of reuse of 'query_exception'. In the new model would that still be the case or would there be more specific new error codes used?
Does not it come out from new results code - the clienterror and servererror part in the tree? Regards Piotr Pikusa
On 4/28/10 6:42 AM, Roman Lapacz wrote:
Hi,
I've attached the lists of result codes which are used in java mdm services (RRD MA and LS).
(Slawek and Piotr, thanks that you had some time to collect them)
Cheers, Roman
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
Hi Piotr; On 5/11/10 10:26 AM, Piotr Pikusa wrote:
Hi Jason!
Jason Zurawski wrote:
RRDMA:
- Are these only for the perfSONAR layer, or do these cover other exceptions that may come up from tomcat/axis/exist?
Those result codes, which were sent present only perfSONAR layer. If some exception comes from eXist it is covered by perfSONAR code. However presented list doesn't cover tomcat and axis errors if they appear besides the perfSONAR code and cannot be catch by it.
- I only see one that uses the 'error.' format: "error.common.storage.xmldb.open". Are these all 'error's or are some of them 'success' too?
Success is only responded by echo request and has a url format. When other requests are completed successfully just a proper message with requested data is sent without any success code and I suppose it is compatible with nmc-wg standard for MA services.
- There is a lot of reuse of 'query_exception'. In the new model would that still be the case or would there be more specific new error codes used?
Does not it come out from new results code - the clienterror and servererror part in the tree?
I am not sure what you mean by 'clienterror' or 'servererror' in this case because we still don't have a complete mapping of how you think all of the old result codes will translate into new. I would expect that this is the next step (we can talk about this on the thursday call). Maybe I wasn't clear enough on my question. From the examples that I am reading for 'query_exception' it covers several cases: - Structure of the message may be wrong, e.g. "no data trigger", "no subject element in metadata id=[...]" - Content in XML is unexpected, e.g. "eventType [...] in metadata id= [...] is not supported" - Content is 'wrong' (not sure how to interpret this, maybe its unexpected or maybe it is just incorrect vs. what is stored in the backend?), e.g. "wrong ipAddress", "wrong hostName" I would call these things different error messages since they cover slightly different cases. My original question was do you or Roman envision these translating directly to a single result code in the new model, or would these be encoded as different codes for different situations. Thanks; -jason
Regards Piotr Pikusa
On 4/28/10 6:42 AM, Roman Lapacz wrote:
Hi,
I've attached the lists of result codes which are used in java mdm services (RRD MA and LS).
(Slawek and Piotr, thanks that you had some time to collect them)
Cheers, Roman
On Tue, 11 May 2010, Jason Zurawski wrote:
Hi Piotr;
On 5/11/10 10:26 AM, Piotr Pikusa wrote:
Hi Jason!
Jason Zurawski wrote:
RRDMA:
- Are these only for the perfSONAR layer, or do these cover other exceptions that may come up from tomcat/axis/exist?
Those result codes, which were sent present only perfSONAR layer. If some exception comes from eXist it is covered by perfSONAR code. However presented list doesn't cover tomcat and axis errors if they appear besides the perfSONAR code and cannot be catch by it.
- I only see one that uses the 'error.' format: "error.common.storage.xmldb.open". Are these all 'error's or are some of them 'success' too?
Success is only responded by echo request and has a url format. When other requests are completed successfully just a proper message with requested data is sent without any success code and I suppose it is compatible with nmc-wg standard for MA services.
- There is a lot of reuse of 'query_exception'. In the new model would that still be the case or would there be more specific new error codes used?
Does not it come out from new results code - the clienterror and servererror part in the tree?
I am not sure what you mean by 'clienterror' or 'servererror' in this case because we still don't have a complete mapping of how you think all of the old result codes will translate into new. I would expect that this is the next step (we can talk about this on the thursday call).
Maybe I wasn't clear enough on my question. From the examples that I am reading for 'query_exception' it covers several cases:
- Structure of the message may be wrong, e.g. "no data trigger", "no subject element in metadata id=[...]" - Content in XML is unexpected, e.g. "eventType [...] in metadata id= [...] is not supported" - Content is 'wrong' (not sure how to interpret this, maybe its unexpected or maybe it is just incorrect vs. what is stored in the backend?), e.g. "wrong ipAddress", "wrong hostName"
I would call these things different error messages since they cover slightly different cases.
My original question was do you or Roman envision these translating directly to a single result code in the new model, or would these be encoded as different codes for different situations.
Moving to the new model will be difficult because meanings of errors may overlap. Let's take 3 examples mentioned above. We can assign them to clienterror/bed_request, clienterror/event_type_not_allowed, clienterror/not_acceptable but this one: clienterror/bed_request, clienterror/event_type_not_allowed, clienterror/bed_request also provides true info about error situations. I'm thinking that maybe we should say that the first part of result code URL is standard but the second part is not controled by NMC. Standard parts of result codes: http://perfsonar.net/status/informational/ http://perfsonar.net/status/successful/ http://perfsonar.net/status/redirection/ http://perfsonar.net/status/clienterror/ http://perfsonar.net/status/servererror/ Example of complete result code: http://perfsonar.net/status/informational/something_which_is_proposed_by_ser... Cheers, Roman
romradz@man.poznan.pl wrote:
On Tue, 11 May 2010, Jason Zurawski wrote:
Hi Piotr;
On 5/11/10 10:26 AM, Piotr Pikusa wrote:
Hi Jason!
Jason Zurawski wrote:
RRDMA:
- Are these only for the perfSONAR layer, or do these cover other exceptions that may come up from tomcat/axis/exist?
Those result codes, which were sent present only perfSONAR layer. If some exception comes from eXist it is covered by perfSONAR code. However presented list doesn't cover tomcat and axis errors if they appear besides the perfSONAR code and cannot be catch by it.
- I only see one that uses the 'error.' format: "error.common.storage.xmldb.open". Are these all 'error's or are some of them 'success' too?
Success is only responded by echo request and has a url format. When other requests are completed successfully just a proper message with requested data is sent without any success code and I suppose it is compatible with nmc-wg standard for MA services.
- There is a lot of reuse of 'query_exception'. In the new model would that still be the case or would there be more specific new error codes used?
Does not it come out from new results code - the clienterror and servererror part in the tree?
I am not sure what you mean by 'clienterror' or 'servererror' in this case because we still don't have a complete mapping of how you think all of the old result codes will translate into new. I would expect that this is the next step (we can talk about this on the thursday call).
Maybe I wasn't clear enough on my question. From the examples that I am reading for 'query_exception' it covers several cases:
- Structure of the message may be wrong, e.g. "no data trigger", "no subject element in metadata id=[...]" - Content in XML is unexpected, e.g. "eventType [...] in metadata id= [...] is not supported" - Content is 'wrong' (not sure how to interpret this, maybe its unexpected or maybe it is just incorrect vs. what is stored in the backend?), e.g. "wrong ipAddress", "wrong hostName"
I would call these things different error messages since they cover slightly different cases.
My original question was do you or Roman envision these translating directly to a single result code in the new model, or would these be encoded as different codes for different situations.
Moving to the new model will be difficult because meanings of errors may overlap. Let's take 3 examples mentioned above. We can assign them to
clienterror/bed_request, clienterror/event_type_not_allowed, clienterror/not_acceptable
but this one:
clienterror/bed_request, clienterror/event_type_not_allowed, clienterror/bed_request
also provides true info about error situations.
I'm thinking that maybe we should say that the first part of result code URL is standard but the second part is not controled by NMC.
Standard parts of result codes: http://perfsonar.net/status/informational/ http://perfsonar.net/status/successful/ http://perfsonar.net/status/redirection/ http://perfsonar.net/status/clienterror/ http://perfsonar.net/status/servererror/
Example of complete result code:
http://perfsonar.net/status/informational/something_which_is_proposed_by_ser...
Cheers, Roman
But then I suppose we must assume that developer will write a code which is understandable by all others, especially client maintainers or client users. I think that this is strong assumption and can provide to the situation that from two different services the same two errors will have very different result code and a client may then think that those two errors are not the same. Cannot we just follow a standard part of results codes presented by you Roman and then bring together non-standard and include them into NMC? It requires developers` agreement on result codes related to the same errors.
On Thu, 13 May 2010, Piotr Pikusa wrote:
romradz@man.poznan.pl wrote:
On Tue, 11 May 2010, Jason Zurawski wrote:
Hi Piotr;
On 5/11/10 10:26 AM, Piotr Pikusa wrote:
Hi Jason!
Jason Zurawski wrote:
RRDMA:
- Are these only for the perfSONAR layer, or do these cover other exceptions that may come up from tomcat/axis/exist?
Those result codes, which were sent present only perfSONAR layer. If some exception comes from eXist it is covered by perfSONAR code. However presented list doesn't cover tomcat and axis errors if they appear besides the perfSONAR code and cannot be catch by it.
- I only see one that uses the 'error.' format: "error.common.storage.xmldb.open". Are these all 'error's or are some of them 'success' too?
Success is only responded by echo request and has a url format. When other requests are completed successfully just a proper message with requested data is sent without any success code and I suppose it is compatible with nmc-wg standard for MA services.
- There is a lot of reuse of 'query_exception'. In the new model would that still be the case or would there be more specific new error codes used?
Does not it come out from new results code - the clienterror and servererror part in the tree?
I am not sure what you mean by 'clienterror' or 'servererror' in this case because we still don't have a complete mapping of how you think all of the old result codes will translate into new. I would expect that this is the next step (we can talk about this on the thursday call).
Maybe I wasn't clear enough on my question. From the examples that I am reading for 'query_exception' it covers several cases:
- Structure of the message may be wrong, e.g. "no data trigger", "no subject element in metadata id=[...]" - Content in XML is unexpected, e.g. "eventType [...] in metadata id= [...] is not supported" - Content is 'wrong' (not sure how to interpret this, maybe its unexpected or maybe it is just incorrect vs. what is stored in the backend?), e.g. "wrong ipAddress", "wrong hostName"
I would call these things different error messages since they cover slightly different cases.
My original question was do you or Roman envision these translating directly to a single result code in the new model, or would these be encoded as different codes for different situations.
Moving to the new model will be difficult because meanings of errors may overlap. Let's take 3 examples mentioned above. We can assign them to
clienterror/bed_request, clienterror/event_type_not_allowed, clienterror/not_acceptable
but this one:
clienterror/bed_request, clienterror/event_type_not_allowed, clienterror/bed_request
also provides true info about error situations.
I'm thinking that maybe we should say that the first part of result code URL is standard but the second part is not controled by NMC.
Standard parts of result codes: http://perfsonar.net/status/informational/ http://perfsonar.net/status/successful/ http://perfsonar.net/status/redirection/ http://perfsonar.net/status/clienterror/ http://perfsonar.net/status/servererror/
Example of complete result code: http://perfsonar.net/status/informational/something_which_is_proposed_by_ser...
Cheers, Roman
But then I suppose we must assume that developer will write a code which is understandable by all others, especially client maintainers or client users. I think that this is strong assumption and can provide to the situation that from two different services the same two errors will have very different result code and a client may then think that those two errors are not the same. Cannot we just follow a standard part of results codes presented by you Roman and then bring together non-standard and include them into NMC? It requires developers` agreement on result codes related to the same errors.
I see your point. So we could define a set of core status codes for each service type or/and common status codes. Other result codes would only support standard parts, e.g. http://perfsonar.net/status/informational/something_which_is_proposed_by_ser... We could start with LS and MA (mdm service maintainer would propose codes for the first and psps service maintainer would do the same for the latter). What do you think? Roman
On Thu, 13 May 2010, romradz@man.poznan.pl wrote:
On Thu, 13 May 2010, Piotr Pikusa wrote:
romradz@man.poznan.pl wrote:
On Tue, 11 May 2010, Jason Zurawski wrote:
Hi Piotr;
On 5/11/10 10:26 AM, Piotr Pikusa wrote:
Hi Jason!
Jason Zurawski wrote:
RRDMA:
- Are these only for the perfSONAR layer, or do these cover other exceptions that may come up from tomcat/axis/exist?
Those result codes, which were sent present only perfSONAR layer. If some exception comes from eXist it is covered by perfSONAR code. However presented list doesn't cover tomcat and axis errors if they appear besides the perfSONAR code and cannot be catch by it.
- I only see one that uses the 'error.' format: "error.common.storage.xmldb.open". Are these all 'error's or are some of them 'success' too?
Success is only responded by echo request and has a url format. When other requests are completed successfully just a proper message with requested data is sent without any success code and I suppose it is compatible with nmc-wg standard for MA services.
- There is a lot of reuse of 'query_exception'. In the new model would that still be the case or would there be more specific new error codes used?
Does not it come out from new results code - the clienterror and servererror part in the tree?
I am not sure what you mean by 'clienterror' or 'servererror' in this case because we still don't have a complete mapping of how you think all of the old result codes will translate into new. I would expect that this is the next step (we can talk about this on the thursday call).
Maybe I wasn't clear enough on my question. From the examples that I am reading for 'query_exception' it covers several cases:
- Structure of the message may be wrong, e.g. "no data trigger", "no subject element in metadata id=[...]" - Content in XML is unexpected, e.g. "eventType [...] in metadata id= [...] is not supported" - Content is 'wrong' (not sure how to interpret this, maybe its unexpected or maybe it is just incorrect vs. what is stored in the backend?), e.g. "wrong ipAddress", "wrong hostName"
I would call these things different error messages since they cover slightly different cases.
My original question was do you or Roman envision these translating directly to a single result code in the new model, or would these be encoded as different codes for different situations.
Moving to the new model will be difficult because meanings of errors may overlap. Let's take 3 examples mentioned above. We can assign them to
clienterror/bed_request, clienterror/event_type_not_allowed, clienterror/not_acceptable
but this one:
clienterror/bed_request, clienterror/event_type_not_allowed, clienterror/bed_request
also provides true info about error situations.
I'm thinking that maybe we should say that the first part of result code URL is standard but the second part is not controled by NMC.
Standard parts of result codes: http://perfsonar.net/status/informational/ http://perfsonar.net/status/successful/ http://perfsonar.net/status/redirection/ http://perfsonar.net/status/clienterror/ http://perfsonar.net/status/servererror/
Example of complete result code: http://perfsonar.net/status/informational/something_which_is_proposed_by_ser...
Cheers, Roman
But then I suppose we must assume that developer will write a code which is understandable by all others, especially client maintainers or client users. I think that this is strong assumption and can provide to the situation that from two different services the same two errors will have very different result code and a client may then think that those two errors are not the same. Cannot we just follow a standard part of results codes presented by you Roman and then bring together non-standard and include them into NMC? It requires developers` agreement on result codes related to the same errors.
I see your point. So we could define a set of core status codes for each service type or/and common status codes. Other result codes would only support standard parts, e.g.
http://perfsonar.net/status/informational/something_which_is_proposed_by_ser...
We could start with LS and MA (mdm service maintainer would propose codes for the first and psps service maintainer would do the same for the latter). What do you think?
...wait, I think I'm categorizing status codes according to service types but we wanted to drop this approach. Roman
romradz@man.poznan.pl wrote:
On Thu, 13 May 2010, romradz@man.poznan.pl wrote:
On Thu, 13 May 2010, Piotr Pikusa wrote:
romradz@man.poznan.pl wrote:
On Tue, 11 May 2010, Jason Zurawski wrote:
Hi Piotr;
On 5/11/10 10:26 AM, Piotr Pikusa wrote:
Hi Jason!
Jason Zurawski wrote: > RRDMA: > > - Are these only for the perfSONAR layer, or do these cover other > exceptions that may come up from tomcat/axis/exist?
Those result codes, which were sent present only perfSONAR layer. If some exception comes from eXist it is covered by perfSONAR code. However presented list doesn't cover tomcat and axis errors if they appear besides the perfSONAR code and cannot be catch by it.
> - I only see one that uses the 'error.' format: > "error.common.storage.xmldb.open". Are these all 'error's or are > some > of them 'success' too? > Success is only responded by echo request and has a url format. When other requests are completed successfully just a proper message with requested data is sent without any success code and I suppose it is compatible with nmc-wg standard for MA services. > - There is a lot of reuse of 'query_exception'. In the new model > would > that still be the case or would there be more specific new error > codes > used? > Does not it come out from new results code - the clienterror and servererror part in the tree?
I am not sure what you mean by 'clienterror' or 'servererror' in this case because we still don't have a complete mapping of how you think all of the old result codes will translate into new. I would expect that this is the next step (we can talk about this on the thursday call).
Maybe I wasn't clear enough on my question. From the examples that I am reading for 'query_exception' it covers several cases:
- Structure of the message may be wrong, e.g. "no data trigger", "no subject element in metadata id=[...]" - Content in XML is unexpected, e.g. "eventType [...] in metadata id= [...] is not supported" - Content is 'wrong' (not sure how to interpret this, maybe its unexpected or maybe it is just incorrect vs. what is stored in the backend?), e.g. "wrong ipAddress", "wrong hostName"
I would call these things different error messages since they cover slightly different cases.
My original question was do you or Roman envision these translating directly to a single result code in the new model, or would these be encoded as different codes for different situations.
Moving to the new model will be difficult because meanings of errors may overlap. Let's take 3 examples mentioned above. We can assign them to
clienterror/bed_request, clienterror/event_type_not_allowed, clienterror/not_acceptable
but this one:
clienterror/bed_request, clienterror/event_type_not_allowed, clienterror/bed_request
also provides true info about error situations.
I'm thinking that maybe we should say that the first part of result code URL is standard but the second part is not controled by NMC.
Standard parts of result codes: http://perfsonar.net/status/informational/ http://perfsonar.net/status/successful/ http://perfsonar.net/status/redirection/ http://perfsonar.net/status/clienterror/ http://perfsonar.net/status/servererror/
Example of complete result code:
http://perfsonar.net/status/informational/something_which_is_proposed_by_ser...
Cheers, Roman
But then I suppose we must assume that developer will write a code which is understandable by all others, especially client maintainers or client users. I think that this is strong assumption and can provide to the situation that from two different services the same two errors will have very different result code and a client may then think that those two errors are not the same. Cannot we just follow a standard part of results codes presented by you Roman and then bring together non-standard and include them into NMC? It requires developers` agreement on result codes related to the same errors.
I see your point. So we could define a set of core status codes for each service type or/and common status codes. Other result codes would only support standard parts, e.g.
http://perfsonar.net/status/informational/something_which_is_proposed_by_ser...
We could start with LS and MA (mdm service maintainer would propose codes for the first and psps service maintainer would do the same for the latter). What do you think?
...wait, I think I'm categorizing status codes according to service types but we wanted to drop this approach.
Roman
Maybe we can't? That was good proposal but when we want to make it real it occurs non-implementable for now? I'm afraid of having some not documented result codes. We can implement this list which is written in your previous e-mail and then follow some non-standard result codes related to particular service type but without writing its type in the result code. It would be like this: http://perfsonar.net/status/informational/MA_Information http://perfsonar.net/status/informational/LS_Information http://perfsonar.net/status/informational/Common_Information_for_LS_and_MA but we should avoid something like this http://perfsonar.net/status/informational/MA/Information http://perfsonar.net/status/informational/LS/Information because of previous discussion about it which shown that this is redundant solution. In this approach we can follow your idea about definitions non standard and also common result codes in NMC. Piotr
Hi All; Comments down below on a couple of things:
romradz@man.poznan.pl wrote:
On Thu, 13 May 2010, romradz@man.poznan.pl wrote:
On Thu, 13 May 2010, Piotr Pikusa wrote:
romradz@man.poznan.pl wrote:
On Tue, 11 May 2010, Jason Zurawski wrote:
Hi Piotr;
On 5/11/10 10:26 AM, Piotr Pikusa wrote: > Hi Jason! > > Jason Zurawski wrote: >> RRDMA: >> >> - Are these only for the perfSONAR layer, or do these cover other >> exceptions that may come up from tomcat/axis/exist? > > Those result codes, which were sent present only perfSONAR layer. If > some exception comes from eXist it is covered by perfSONAR code. > However > presented list doesn't cover tomcat and axis errors if they appear > besides the perfSONAR code and cannot be catch by it. > >> - I only see one that uses the 'error.' format: >> "error.common.storage.xmldb.open". Are these all 'error's or are >> some >> of them 'success' too? >> > Success is only responded by echo request and has a url format. When > other requests are completed successfully just a proper message with > requested data is sent without any success code and I suppose it is > compatible with nmc-wg standard for MA services. >> - There is a lot of reuse of 'query_exception'. In the new model >> would >> that still be the case or would there be more specific new error >> codes >> used? >> > Does not it come out from new results code - the clienterror and > servererror part in the tree?
I am not sure what you mean by 'clienterror' or 'servererror' in this case because we still don't have a complete mapping of how you think all of the old result codes will translate into new. I would expect that this is the next step (we can talk about this on the thursday call).
Maybe I wasn't clear enough on my question. From the examples that I am reading for 'query_exception' it covers several cases:
- Structure of the message may be wrong, e.g. "no data trigger", "no subject element in metadata id=[...]" - Content in XML is unexpected, e.g. "eventType [...] in metadata id= [...] is not supported" - Content is 'wrong' (not sure how to interpret this, maybe its unexpected or maybe it is just incorrect vs. what is stored in the backend?), e.g. "wrong ipAddress", "wrong hostName"
I would call these things different error messages since they cover slightly different cases.
My original question was do you or Roman envision these translating directly to a single result code in the new model, or would these be encoded as different codes for different situations.
Moving to the new model will be difficult because meanings of errors may overlap. Let's take 3 examples mentioned above. We can assign them to
clienterror/bed_request, clienterror/event_type_not_allowed, clienterror/not_acceptable
but this one:
clienterror/bed_request, clienterror/event_type_not_allowed, clienterror/bed_request
also provides true info about error situations.
I'm thinking that maybe we should say that the first part of result code URL is standard but the second part is not controled by NMC.
Standard parts of result codes: http://perfsonar.net/status/informational/ http://perfsonar.net/status/successful/ http://perfsonar.net/status/redirection/ http://perfsonar.net/status/clienterror/ http://perfsonar.net/status/servererror/
Example of complete result code:
http://perfsonar.net/status/informational/something_which_is_proposed_by_ser...
As discussed on the call - overlap is bound to happen. I think the right way to go forward is to try to perform the mapping of the current codes into the new tree. If things map into multiple spaces then we note that. We can always go back later and try to make the 'correct' decision where things should land. We just need a place to start. As for the example above where the developer has control over the 'last' stanza of the code - I think this is the wrong thing to do. The whole point of standardizing the codes to eliminate this. Thanks; -jason
Cheers, Roman
But then I suppose we must assume that developer will write a code which is understandable by all others, especially client maintainers or client users. I think that this is strong assumption and can provide to the situation that from two different services the same two errors will have very different result code and a client may then think that those two errors are not the same. Cannot we just follow a standard part of results codes presented by you Roman and then bring together non-standard and include them into NMC? It requires developers` agreement on result codes related to the same errors.
I see your point. So we could define a set of core status codes for each service type or/and common status codes. Other result codes would only support standard parts, e.g.
http://perfsonar.net/status/informational/something_which_is_proposed_by_ser...
We could start with LS and MA (mdm service maintainer would propose codes for the first and psps service maintainer would do the same for the latter). What do you think?
...wait, I think I'm categorizing status codes according to service types but we wanted to drop this approach.
Roman
Maybe we can't? That was good proposal but when we want to make it real it occurs non-implementable for now? I'm afraid of having some not documented result codes. We can implement this list which is written in your previous e-mail and then follow some non-standard result codes related to particular service type but without writing its type in the result code. It would be like this:
http://perfsonar.net/status/informational/MA_Information http://perfsonar.net/status/informational/LS_Information http://perfsonar.net/status/informational/Common_Information_for_LS_and_MA
but we should avoid something like this http://perfsonar.net/status/informational/MA/Information http://perfsonar.net/status/informational/LS/Information
because of previous discussion about it which shown that this is redundant solution.
In this approach we can follow your idea about definitions non standard and also common result codes in NMC.
Piotr
Moving to the new model will be difficult because meanings of errors may overlap. Let's take 3 examples mentioned above. We can assign them to
clienterror/bed_request, clienterror/event_type_not_allowed, clienterror/not_acceptable
but this one:
clienterror/bed_request, clienterror/event_type_not_allowed, clienterror/bed_request
also provides true info about error situations.
I'm thinking that maybe we should say that the first part of result code URL is standard but the second part is not controled by NMC.
Standard parts of result codes: http://perfsonar.net/status/informational/ http://perfsonar.net/status/successful/ http://perfsonar.net/status/redirection/ http://perfsonar.net/status/clienterror/ http://perfsonar.net/status/servererror/
Example of complete result code: http://perfsonar.net/status/informational/something_which_is_proposed_by_ser...
Still thinking about it :) Pieces in result code like successful, clienterror, servererror are not enough for us for automatic categorization done by a receiver (e.g. client app)? Second part of result code would be just human readable. Do our client apps use detailed result code information for automatic actions? If we needed a more detailed result code for a specific automatic action we could add it to NMC. Roman
Cheers, Roman
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
clienterror/not_acceptable/ - not further specified means it's a bad request but we don't know why(not sure if we should allow that) clienterror/not_acceptable/bad_request/ clienterror/not_acceptable/bad_request/event_type_not_allowed - I'm using this as an example because it was used before not because I agree with this error formulation as it tells me nothing? clienterror/not_acceptable/needs_authorization (perhaps something better would be information required to do authorization was not supplied (but thats kinda long ;) clienterror/not_acceptable/request_too_large clienterror/too_many_requests - this is when one client(ip?) sends too many request - hence it being client error, there could also be a servererror variant which means the server is too busy/being DoS-ed etc. My original question was do you or Roman envision these translating directly to a single result code in the new model, or would these be encoded as different codes for different situations. They should probably map - given that they make sense in the first place - to a single result code _with a common 'base'_(the left size of / exmple <BASE>/<MORE_SPECIFIC_BASE>/result_code I suppose you could call it parent too if you view it as a tree of values. Michael On Thu, May 13, 2010 at 4:43 PM, romradz@man.poznan.pl <romradz@man.poznan.pl> wrote:
Moving to the new model will be difficult because meanings of errors may overlap. Let's take 3 examples mentioned above. We can assign them to
clienterror/bed_request, clienterror/event_type_not_allowed, clienterror/not_acceptable
but this one:
clienterror/bed_request, clienterror/event_type_not_allowed, clienterror/bed_request
also provides true info about error situations.
I'm thinking that maybe we should say that the first part of result code URL is standard but the second part is not controled by NMC.
Standard parts of result codes: http://perfsonar.net/status/informational/ http://perfsonar.net/status/successful/ http://perfsonar.net/status/redirection/ http://perfsonar.net/status/clienterror/ http://perfsonar.net/status/servererror/
Example of complete result code: http://perfsonar.net/status/informational/something_which_is_proposed_by_ser...
Still thinking about it :) Pieces in result code like successful, clienterror, servererror are not enough for us for automatic categorization done by a receiver (e.g. client app)? Second part of result code would be just human readable. Do our client apps use detailed result code information for automatic actions? If we needed a more detailed result code for a specific automatic action we could add it to NMC.
Roman
Cheers, Roman
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
participants (5)
-
Jason Zurawski -
Michael Bischoff -
Piotr Pikusa -
Roman Lapacz -
romradz＠man.poznan.pl