perfsonar development work

[Roman Lapacz <>]

Roman Lapacz wrote:
> Jason Zurawski wrote:
> > >
> >
> >
> > I still am confused as to why you feel 'supportedEventType' 
> > parameters are a much better fit than eventType in this case, they 
> > are describing the same exact thing except that eventType is more 
> > direct than a parameters block.  The old style may have filled a need 
> > during the early development, but if we are going to progress to 
> > supporting multiple metrics using the same descriptions we should try 
> > more concrete solutions instead of workarounds.
>
> I would prefer to keep parameters to group supported event types 
> (first we had eventType element but after a while we decided to switch 
> to parameters as grouping solution) but I'm not against to come back 
> to eventType.
>
> > Also, in your example how do we know which supportedEventTypes belong 
> > to the different key descriptions?  There needs to be a way to 
> > specify what capabilities are available in a key, especially in 
> > instances we we do not want to repeat a key description.
> I see your point.
>
>
>
> > > > > 6) 
> > > > > http://anonsvn.internet2.edu/svn/nmwg/branches/snmp/example_instances/errors/MDKRequest2.xml 
> > > > >
> > > > >
> > > > > Parameters in the key in metadata m3 represent more than one 
> > > > > namespace so it should look like this:
> > > > >
> > > > >    <nmwg:key id="1">
> > > > >      <nmwg:parameters id="1">
> > > > >        <nmwg:parameter 
> > > > > name="supportedEventType">http://ggf.org/ns/nmwg/characteristic/errors/2.0</nmwg:parameter> 
> > > > >
> > > > >        <nmwg:parameter name="type">rrd</nmwg:parameter>
> > > > >        <nmwg:parameter name="valueUnits">Eps</nmwg:parameter>   
> > > > >        <nmwg:parameter 
> > > > > name="file">/home/jason/perfSONAR-PS/MP/SNMP/mead.rrd</nmwg:parameter> 
> > > > >
> > > > >        <nmwg:parameter 
> > > > > name="dataSource">eth0-ifInErrors</nmwg:parameter>
> > > > >      <nmwg:parameters id="2">
> > > > >      <select:parameters id="2">
> > > > >        <nmwg:parameter name="startTime" value="N-50" />
> > > > >        <nmwg:parameter name="endTime" value="N" />
> > > > >        <nmwg:parameter name="resolution" value="1" />
> > > > >        <nmwg:parameter name="consolidationFunction" 
> > > > > value="AVERAGE" />           </select:parameters>
> > > > >    </nmwg:key>
> > > > >
> > > > > This approach should be used in requests and responses.
> > > > This is too cumbersome and allowing multiple parameters blocks 
> > > > doesn't look correct in this case.  We really should use a chain to 
> > > > describe what is going on, or because the contents of the key is 
> > > > opaque it should not matter what namespace is used to describe the 
> > > > internals.
> > > I think it's quite clear and straightforward. Right, what's inside 
> > > does not matter for a client but for a service might be interesting 
> > > and needed not to lose context of parameters. Having all parameters 
> > > in one namespace nmwg, which in fact might be wrong for some of 
> > > them, is losing some information.
> >
> > There is no information loss because the key has been 'cooked' in one 
> > of its previous visits and the server has organized the information 
> > in a format it likes, including extra parameters blocks in various 
> > namespaces really only aids humans as they examine the key (which 
> > they shouldn't do anyway as it is opaque).
> > Ideally we shouldn't be passing back a clear key where it is obvious 
> > to see what we have done (the key structure if I recall correctly 
> > should be used to save state on the server end), we should start 
> > moving to an obfuscated key that means nothing by sight.
>
> I agree with you that the key has no meaning for a client but a 
> request with key for service side is a different case. Why not to keep 
> namespaces as originally? It might be useful for RRD MA (at least for 
> Java implementation). It will not be the rule for all services of 
> course. Other services might use totally different keys (even without 
> parameters :) In fact, client app should not generate keys, it should 
> get it from a service.

In case of not losing namespaces in the key we will not have the problem 
if there will be the same names of parameters representing different 
namespaces.


  <nmwg:key>
    <n1:parameters id="1">
      <nmwg:parameter name="xxx">123</nmwg:parameter>
      ....
    <n1:parameters>
    <n2:parameters id="2">
      <nmwg:parameter name="xxx">567</nmwg:parameter>
       ....
    </n2:parameters>
  </nmwg:key>


Roman