Roman Lapacz wrote:
Jeff
W. Boote wrote:
Slawomir,
Thank you for the proposal. We definitely need to get some agreement
here, and this is a good start to the discussion.
I believe the first solution will cause redundant codes in multiple
areas. Is an error in one service-type really different from an error
in another service-type from the perspective of the client? Remember,
the result-codes are there to communicate state to the client and the
_expression_ of that state should be done in a way that makes it as
simple as possible to implement a client. This is not about making it
easy to develop a service.
If the problem is 'not enough resources', then it does not make sense
to me that we create that kind of a result-code for each and every
'type' of service. Besides, service types are often a pretty arbitrary
distinction. There are many services that act in several 'types of
service' roles. (MPs and MAs are often coded as a single service
together.)
I'd like to suggest a modification of the 3rd suggestion since I
believe it is based on ideas that I suggested to Jason, but I don't
believe this proposal really articulates what I was trying to suggest.
A client needs to be able to decode error codes in a much more simple
way. I would like to suggest something far more simple here.
Specifically, when I suggested modeling this after http status messages
(or I also said errno values would be a reasonable model as well) you
will see that they are grouped: (Basing this on
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html)
informational 1xx
successful 2xx
redirection 3xx
client error 4xx
server error 5xx
I like the idea although I'm not sure to separate errors into client
and server types. Definition of category should be explicit but
examples below may raise questions, for example, whether 'request too
large' is a client error (how the limits are specified? in case of
large metadata key request the problem may be in the performance of
server side) or server error?
From the client developer point of view, I like the idea of following
HTTP style status codes.
Client errors[1] are due to the client sending incorrect data,
according to some rules, specified by the server or application. In
case of request too large, it is a client error (the limit is specified
by the server - e.g. limits for size of uploading file are specified
by the server).
10.4.14 413 Request Entity Too Large
The server is refusing to process a request because the
request entity is larger than the server is willing or able to process.
The server MAY close the connection to prevent the client from
continuing the request.
If the condition is temporary, the server SHOULD include a
Retry- After header field to indicate that it is temporary and after
what time the client MAY try again.
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
Best regards,
Nina
Roman
So, using perfSONAR URL syntax, I would expect to see to support this
would look more like:
http://schema.perfsonar.net/status/
|
|---- info/
| | -- might not use this one...
|---- successful
| | -- registration
| | -- metadatakeyresponse
| | -- "any protocol response, but based on protocol messages
not on service types"...
|----redirection
| | -- not sure we need this, but it could be used for hLS
redirecting
|---- client error
| | -- bad request
| | -- unauthorized
| | -- forbidden
| | -- not found/no data
| | -- eventType not allowed
| | -- request timeout
| | -- conflict (for example, too many users)
| | -- request too large (size of message)
| | -- request range needed (size of response would be too big)
|---- server error
| | -- internal server error
| | | -- back-end database check failed
| | -- not implemented
| | -- service unavailable (temporary failure)
| | -- protocol version unsupported
If specific services want to provide more information - they can
specialize these messages. The advantage here is of course that clients
don't really care if something is an MA or an MP, what they care about
is if the result-code says successful or not, and if the error
indicates they should try again or not. And, if services make something
more specialized, the client can ignore the trailing bits of the URL
past the part that they care about.
jeff
On Nov 5, 2009, at 6:21 AM, Piotr Pikusa wrote:
Hi all!
Thank you Slawek for this document! For me the first proposal is well
done. It's clear, it takes into account function of the service sending
a response. I think that the second conception is too general and third
is too specialist. Of course the third one is very comfortable for a
developer engaged in particular service because one create new
eventType without looking at other services. But it could lead to
redundant entries describing the same functionality with different
ulrs. Advantage of the first idea is when one create new service,
he/she sees all other eventTypes and doesn't have to invent anything
new. And also one keeps compatibility.
To sum up - Third solution seems to be the fastest to agree, but the
first one is the clearest and most elegant.
Cheers
Piotr Pikusa
Slawomir Trzaszczka wrote:
On Fri, 2009-09-25 at 10:08 +0200,
Slawomir Trzaszczka wrote:
Hi,
I would like to describe you three proposals of event types hierarchy.
Event types (result codes) described in this document are related ONLY
with RESPONSE message. So, I would like to show you some inconsistency
between event types in requests and response what is the one of purpose
to use new event type policy (result codes). In this example I depict
echo message.
-----------------------ECHO REQUEST--------------------------------
<nmwg:message xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"
type="EchoRequest">
<nmwg:metadata id="meta">
<nmwg:eventType>
http://schemas.perfsonar.net/tools/admin/echo/2.0
</nmwg:eventType>
</nmwg:metadata>
<nmwg:data id="data" metadataIdRef="meta"/>
</nmwg:message>
-------------------------------------------------------------------
response for this message (dotted notation of event types)
-----------------------ECHO RESPONSE--------------------------------
<nmwg:message type="EchoResponse">
<nmwg:metadata id="resultCodeMetadata">
<nmwg:eventType>success.echo</nmwg:eventType>
</nmwg:metadata>
<nmwg:data metadataIdRef="resultCodeMetadata">
<nmwgr:datum>This is the echo response from the
service.</nmwgr:datum>
</nmwg:data>
</nmwg:message>
--------------------------------------------------------------------
As you can see there is a big "inconsistency". Hence we would like to
use url event types policy in result codes(similar to event types in
requests). The question is how this event types can be placed in
hierarchy. We have three proposals of this hierarchy, so I would like
to
invite you to common discussion about it. This change is very important
for all perfsonar services. This change, move from dotted notation to
url, will influence on event types format in responses, so I strongly
encourage you to this discussion!.
Regards,
Slawek
Hi all,
I would like to ask you few questions about eventTypes format. Some
times ago it was a discussion about eventTypes format. The common
decision was URL format for eventTypes in requests and responses
(example below)
----------------
EXAMPLE
echo for LookupService
old version - dotted notation eventType
<nmwg:metadata id="resultCodeMetadata">
<nmwg:eventType>success.echo</nmwg:eventType>
</nmwg:metadata>
new version - URL notation
<nmwg:metadata id="result-code">
<nmwg:eventType>http://perfsonar.net/result/success/echo</nmwg:eventType>
</nmwg:metadata>
-----------------------------
After discussion with Jason we decided that we have to define
eventType
hierarchy together. So What is your proposal of this hierarchy ?.
I send you links with eventTypes hierarchy in old 'dotted' version and
hierarchy of it in some services :
examples of the eventTypes in services :
https://wiki.man.poznan.pl/perfsonar-mdm/index.php/Result_code_hierarchy
hierarchy tree of eventTypes :
https://wiki.man.poznan.pl/perfsonar-mdm/index.php/Result_code_hierarchy
I think that we should test our services, apis and check What kind of
eventTypes do we use. In next release we would like to use only URL
eventTypes.
Every proposal for eventTypes hierarchy will be helpful.
Regards,
Slawomir
|
