perfsonar development work

[Antoine Delvaux <>]

Hi Slawomir, Jeff, All,

Yes, this is good we discuss all that, thanks for initiating  
discussion Slawek.

Jeff, I like your view about making things as simple as possible for  
the client, this will make the protocol simpler, I guess this is all  
what we want to achieve.  I also like your idea to mimic HTTP status  
messages.

However, I don't understand why we need another layer on top of the  
existing HTTP status messages, but maybe it's because I'm not that  
familiar with pS protocol, bear with me then.  Couldn't we use HTTP  
status messages and add to it more description to the result code.  A  
full response (including HTTP headers) would then be something like:

_Success example_:

HTTP/1.1 200 Ok
Content-Type:"text/xml"; Charset="utf-8"
Content-Length: nnnn

<nmwg:message type="EchoResponse">
<nmwg:metadata id="resultCodeMetadata">
   <nmwg:eventType>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>

_Error example_:

HTTP/1.1 500 Internal Server Error
Content-Type: "text/xml"; Charset="utf-8"
Content-Length: nnnn

<nmwg:message type="EchoResponse">
<nmwg:metadata id="resultCodeMetadata">
   <nmwg:eventType>not implemented</nmwg:eventType>
</nmwg:metadata>
<nmwg:data metadataIdRef="resultCodeMetadata">
   <nmwgr:datum>EchoResponse command doesn't exist.</nmwgr:datum>
</nmwg:data>
</nmwg:message>

On a side note, except for the sake of coherence between requests and  
answers, I don't see the need to use URL in eventType naming.  IMHO,  
it seems to me that URN would be more suited in this situation.  Or is  
there some convention in OGF that it's best to use URL?

Best regards,

Antoine.

Le 8 nov. 2009 à 08:36, Jeff W. Boote a écrit :

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

--
Antoine Delvaux                                    Systems Engineer
DANTE                                                 Skype: toninb
http://www.dante.net                            Tel: +221.776530462
PGP fingerprint: DC65 0D8B 6938 9229 33C3  18CA 4EB6 09D3 A333 3378