perfsonar development work

[Slawomir Trzaszczka <>]

On Sun, 2009-11-08 at 01:36 -0700, 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.

Sorry, 
Maybe I didn't understand your conception ;).


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

Your proposal is very flexible. I fully agree with it !. It is extended
version of second proposal (grouped by functionality),

Regards,

Slawek 

> 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
> >>>
> >>>
> >>
> >>
> >
> 
-- 
+--------------------------------------------+
 Slawomir Trzaszczka                       
                                           
 Poznan Supercomputing & Networking Center 
+--------------------------------------------+