perfsonar development work

["Nina Jeliazkova" <>]

Roman Lapacz 
<>
 wrote:

> Nina Jeliazkova wrote:
> > Maciej Glowiak 
> > <>
> >  wrote:
> >
> >   
> >> Nina Jeliazkova wrote:
> >>     
> >>> Hi all,
> >>>
> >>> Initially, I had no preferences in either ot the proposals, what worries
> >>>       
> > me
> >   
> >> a
> >>     
> >>> bit is the ability of introducing new options/parameters without
formally
> >>> changing the schema. 
> >>>
> >>> While it seems to facilitate the work of service developers, IMHO it is
> >>>       
> > not
> >   
> >>> quite the same for the client. The client will still need to be modified
> >>>       
> > in
> >   
> >>> order to reflect the semantics of those parameters, resulting in clients
> >>> declaring support for schema X, but possible interpreting messages
> >>> differently. If it is OK for other developers, please ignore my
comments.
> >>>       
> >> Nina, please correct me if I understood you wrong.
> >>
> >> My intention was to just change the syntax of Lookup Information. Of 
> >> course client apps will need to be changed, but the change shouldn't be 
> >> so big - it's just different structure. Instead of looking for e.g. 
> >> service name in metadata/subject/service/serviceName you will need to 
> >> check 
> >> metadata/parameters/parameter[@name='serviceName'].
> >>
> >> Of course for some time there may be problem with various versions of 
> >> lookup info, but LS may do the translation from old structure and store 
> >> new values as parameters.
> >>
> >> Most of developers using LS registration use generic component for 
> >> registration, so the change will also be in one place and will be 
> >> transparent for them.
> >>
> >> Maciej
> >>
> >>     
> >
> > Maciej,
> >
> > Yes, I understand this will be a slight change in the query. The problem I
> am
> > thinking about is having those changes labeled as the same schema version
-
> in
> > this case how a client that needs to support multiple versions will guess
> > there are differences? If it is not the case, your proposal is fine for
me.
> >   
> 
> Maybe using different namespace for such parameters element could solve 
> the problem with versions (namespaces contains version numers)
> 
> 
> updated Maciej's example:
> 
> 
> <nmwg:metadata id="lookup-info">
>   <lookupinfo:parameters 
> xmlns:select="http://ggf.org/ns/nmwg/lookupinfo/2.0/";>
> 
>      <nmwg:parameter name="serviceName" value="Java RRD MA" />
>      <nmwg:parameter name="accessPoint" value="http://shower.fr:8080"; />
>      <nmwg:parameter name="serviceType" value="MA" />
>      <nmwg:parameter name="serviceDescription"
>            value="Java RRD MA, perfSONAR project, 229.148.249.60" />
> 
>      <nmwg:parameters name="supportedEventTypes">
>          <nmwg:parameter name="eventType1"
>                          value="http://.../utilization/>
>          <nmwg:parameter name="eventType2"
>                          value="http://.../l2-path-status/>
>      </nmwg:parameters>
> 
>   </lookupinfo:parameters>
> </nmwg:metadata>
> 
> 
> Roman
> 

Yes, seems reasonable.

Nina

> 
> > Regards,
> > Nina
> >
> >
> >
> >
> >   
>