perfsonar development work

[Jason Zurawski <>]

Roman;


> > > 2) 
> > > http://anonsvn.internet2.edu/svn/nmwg/branches/snmp/example_instances/errors/store.xml 
> > >
> > >
> > > supportedEventType parameter is not needed in the key. Data element 
> > > with a key refers to metadata where supportedEventType is present.
> > We will need to have this in the key (or perhaps just eventType) for 
> > situations when a metadata element describes multiple eventTypes, and 
> > may be used by several data blocks w/ keys.  Consider a metadata 
> > description  that is used for utilization, errors, and discards.  The 
> > corresponding RRD description may use two files (one for utilization, 
> > another for errors/discards):
> Using parameters element with supportedEventType parameters fits here 
> perfectly. metadataIdRef of data element points to ceratin metadata 
> element with relevant supportedEventType parameter.
>
> <metadata id="1">
>  <parameters>
>    <parameter name="supportedEventType">1</parameter>
>    <parameter name="supportedEventType">2</parameter>
>    <parameter name="supportedEventType">3</parameter>
>  </parameters>
> </metadata>
>
> <data id="d1" metadataIdRef="1">
>  <key>
>    file1
>    ds0
>  </key>
> </data>
>
> <data id="d2" metadataIdRef="1">
>  <key>
>    file1
>    ds1
>  </key>
> </data>
>
> <data id="d3" metadataIdRef="1">
>  <key>
>    file2
>    ds0
>  </key>
> </data>


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. 

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. 



> > > 3) 
> > > http://anonsvn.internet2.edu/svn/nmwg/branches/snmp/example_instances/errors/store.xml 
> > >
> > >
> > > This file is store file so metadata should contain this:
> > >
> > >        <nmwg:parameters>
> > >            <nmwg:parameter 
> > > name="supportedEventType">http://ggf.org/ns/nmwg/characteristic/errors/2.0</nmwg:parameter> 
> > >
> > >        </nmwg:parameters>
> > >
> > > instead of this:
> > >
> > >        
> > > <nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/errors/2.0</nmwg:eventType> 
> >
> >
> > We should move away from 'supportedEventType' and start using actual 
> > eventTypes so we can get rid of the layer of indirection that 
> > parameters gives us.
>
> I don't see the problem in using parameters here



But why bother with using parameters to describe 'supported' eventTypes 
when we are actually describing an eventType?  We are abstracting out 
when we don't need to in this case. 




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

-jason