perfsonar development work

[Jeff W.Boote <>]

These optional parameters would not be known past the hLS because they  
are not part of the summary-set that is registered to the gLS from the  
hLS, so I'm not sure this would buy you much. i.e. it would not allow  
services to be discoverable using them.

And, if you think about what will be required to modify the summary  
set, you will see that this is not something we want to change  
lightly... I'm not saying we shouldn't really think about what  
information about services we want to use to make services  
discoverable, but I really think we need to start with use cases. Not  
schema fragments.

jeff

On Nov 10, 2009, at 5:08 AM, Roman Lapacz wrote:

> Jason Zurawski wrote:
> > All;
> >
> > I think that Jeff's clarifications make proposal 3 better.  My only  
> > question/thought is about the last part of Jeff's proposal:
> >
> > > > The advantage here is of course that clients don't really care if  
> > > > something is an MA or an MP <snip>
> >
> > Would this always be the case?  I am not sure of the answer but we  
> > have always labored under the assumption (perhaps more ideally than  
> > practically) that _where_ the error comes from provided a valuable  
> > piece of information.  For 'dumb' clients that care about data and  
> > data alone, I presume it doesn't matter - is there a case where it  
> > would?
>
> Maybe additional _optional_ parameter elements (those used when a  
> service registers in LS) inside metadata would be useful to provide  
> more information.
>
> <nmwg:message>
> <nmwg:metadata id="resultCodeMetadata">
>  <nmwg:eventType>http://....</nmwg:eventType>
>  <nmwg:parameters>
>    <nmwg:parameter name="serviceType">zzz<nmwg:parameter>
>    <nmwg:parameter name="serviceName">yyy<nmwg:parameter>
>  <nmwg:parameters>
> </nmwg:metadata>
> <nmwg:data metadataIdRef="resultCodeMetadata">
>  <nmwgr:datum>xxxxxxx</nmwgr:datum>
> </nmwg:data>
> </nmwg:message>
>
>
> Roman
>
>
> > -jason
> >
> >
> > > 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