perfsonar development work

["Jeff W. Boote" <>]

Jason Zurawski wrote:
> Hey Roman;
>
> > How could we indicate that the first filtering parameters 
> > (meta2select) use unix time type and the second one (meta4select) use 
> > ISO 8601. Now we have high level parameter timeType (see attachment)
> >
> >  <nmwg:parameters id="msgparam1">
> >    <nmwg:parameter name="timeType">unix</nmwg:parameter>
> >  </nmwg:parameters>
>
>
> I see from the example that this is at the message level, which works 
> but in my opinion is not ideal.
>
> > We might add new parameter into filtering parameters' metadata, example:
> >
> >  <nmwg:metadata id="meta2select">
> >    <select:subject id="iusub2" metadataIdRef="meta1"/>
> >    <select:parameters id="param1">
> >      <nmwg:parameter name="startTime">1121472000</nmwg:parameter>
> >      <nmwg:parameter name="endTime">1121904000</nmwg:parameter>
> >      <nmwg:parameter 
> > name="consolidationFunction">AVERAGE</nmwg:parameter>
> >      <nmwg:parameter name="resolution">60</nmwg:parameter>
> >      <nmwg:parameter name="timeType">unix</nmwg:parameter>
> >    </select:parameters>
> >    <nmwg:eventType>http://ggf.org/ns/nmwg/ops/select/2.0</nmwg:eventType>
> >  </nmwg:metadata>
> >
> >
> > what do you think? Maybe there is more general approach?
>
> I think this is a good use of a parameter (and because it is specific 
> for this particular implementation it shouldn't affect any other 
> service).  I am not sure if it should be in the select parameter block, 
> along with other RRD specific parameters however.  The time type is an 
> external modification to the data presentation, the CF, resolution and 
> start/end times are sent to the RRD libraries.  It could be in a 
> seperate parameter block:
>
> <nmwg:parameters>
>  <nmwg:parameter name="timeType">unix</nmwg:parameter>
> </nmwg:parameters>
> <select:parameters>
>  <select:parameter ... />
> </select:parameters>

I'm probably going to get yelled at because what I'm going to suggest is more 
complex - but I really don't like the timeType parameter solution. In my 
opinion, all parameters that are of 'type' time should be set using an nmtm:time 
element.

I'm fine with the the concept that the 'default' translation from 'string' to 
nmtime treats the 'string' as an ascii representation of the unix timestamp. 
That would make this backward compatible. But, I would far prefer to see each 
'time' parameter treated as a specific time type. We (nmwg) spent a lot of time 
(years) agreeing how to best represent time. I believe there is benefit in 
strongly typing the time parameters.

I realize this means that parameters would need to be able to accept 'typed' 
parameters. This is something we have needed to add for a very long time.  Time 
is only one example of this - and as we have more and more complex data types in 
the future this same issue is going to come up again and again.

jeff