perfsonar development work

["Nina Jeliazkova" <>]

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.

Best regards,
Nina


Maciej Glowiak 
<>
 wrote:

> Verena Venus wrote:
> > Hi all,
> > 
> > Am Tuesday 10 July 2007 00:01 schrieb Jeff W. Boote:
> >> Maciej Glowiak wrote:
> >>> Sorry, small mistake (in supportedEventTypes), it should be:
> >>>
> >>> --------------------------------------------------------------
> >>> <nmwg:metadata id="lookup-info">
> >>>   <nmwg:parameters id="lookup-info">
> >>>
> >>>      <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:parameter name="supportedEventTypes">
> >>>         <nmwg:parameters id="eventTypes">
> >>>             <nmwg:parameter name="eventType1"
> >>>                             value="http://.../utilization/"; />
> >>>             <nmwg:parameter name="eventType2"
> >>>                             value="http://.../l2-path-status/"; />
> >>>         </nmwg:parameters>
> >>>     </nmwg:parameter>
> >>>
> >>> </nmwg:metadata>
> >>> --------------------------------------------------------------
> >>>
> >>> But anyway, the question was about general idea of such change.
> >> I already gave my opinion of the general change. But, I'm curious about
the
> >> specifics here as well.
> >>
> >> Why not just use:
> >>
> >> <nmwg:parameter name="supportedEventTypes">
> >>      <nmwg:eventType>eventType1</nmwg:eventType>
> >>      <nmwg:eventType>eventType2</nmwg:eventType>
> >>      <nmwg:eventType>eventType3</nmwg:eventType>
> >>      <nmwg:eventType>eventType4</nmwg:eventType>
> >>      <nmwg:eventType>eventType5</nmwg:eventType>
> >> </nmwg:parameter>
> >>
> >> I don't really see the reason to put another parameters container in. Or
> >> any reason to use a list of parameters inside this either.
> >>
> > 
> > I totally agree. I think it's a little bit confusing to have parameters
> inside 
> > parameters....
> > 
> > The scheme proposed by Jeff looks sensible to me.
> 
> 
> Hi, Verena
> 
> That's ok for me. But I based on something what was already agreed, 
> that's why parameters inside parameter. The second thing is I am not 
> sure it doesn't require schema and implementation change. Of course it 
> may be done, but my intention was to make the change as simple/quick as 
> possible using existing schema and solutions already made.
> 
> Maciej