perfsonar development work

[Roman Lapacz <>]

Jeff W. Boote wrote:
> maxim wrote:
> >  
> > > type is currently used for all current 'time' based parameter 
> > > elements in existing services.
> >  what are the  'time' based parameters ? I know only one parameter 
> > and as far as
> > there is only definition for this parameter in schema then there is 
> > no "type" attribute.
> >  
> >
> > Just checked the most recent one under: 
> > trunk/geant2_java-rrd-ma/doc/schema/
> >
> > Its still:
> > ---------------------
> > Parameter =
> >         element nmwg:parameter {
> >         attribute name { xsd:string } &
> >                 (
> >                         attribute value { xsd:string } |
> >                         xsd:string
> >                 )
> >         }
> > -----------------------------------
>
> Ah - right you are. My mistake. I thought we were using the same 
> construct in parameters that is used in datum. (Yes, this is a good 
> example for why we should be handling time uniformly.)
>
> After looking closer, it looks like the current state of the services 
> is (Roman/Jason - please correct me if I'm wrong):
>
> Time related parameters such as "startTime", "endTime" are assumed to 
> be unix strings.

yes

> (Roman apparently supports nmtime child objects as well, but it is not 
> in the interface doc. ;) )

I didn't add this because the Release Team didn't mention it was needed 
(not sure if client apps support it). Maybe this should be clarified.


Roman



> My suggestion going forward is this:
>
> 1) keep 'startTime' and 'endTime' parameters for at least the next 
> major release - perhaps even the one after that. These parameters can 
> be specified with String's that will be interpreted as 'unix' 
> timestamps (as they are now). Or, they can be an nmtime element - but 
> only the TimeStamp variety. (no start/end child elements allowed - 
> these would be a semantic error)
>
> 2) add a 'timeRange' parameter (I don't care the name) which is 
> specified using a general nmtime element child, which must specify a 
> range using the start/end or start/duration syntax.
>
> 3) eventually deprecate 'startTime' and 'endTime' as direct parameters.
>
> jeff