perfsonar development work

[Roman Lapacz <>]

Jeff W. Boote wrote:
> My simplistic approach was going to be to support something like this 
> for current time parameters:
>
> <nmwg:parameter name="startTime" type="nmtime">
>     <nmtm:time> <!-- see nmtime.rnc --> </nmtm:time>
> </nmwg:parameter>
Hi,

java ma service already supports something like this:

     <nmwg:parameter name="startTime">
         <nmtm:time type="ISO" value="2007-08-10T10:40:00Z"/>
     </nmwg:parameter>
     <nmwg:parameter name="endTime">
         <nmtm:time type="ISO" value="2007-08-10T11:45:00Z"/>
     </nmwg:parameter>


I agree with you that we should start using nmtm time element(s).

Roman


> For new parameters of type 'time' the 'type' attribute would not be 
> needed because the child element type could be directly put in the rnc 
> file along with the parameter name enumerations.
>
> I realize this does not add a bunch of functionality over type = 
> "unix" for something as simple as selection. It does however localize 
> the time handling, and this simple case could be handled using the 
> same syntax rules/code as the more complex ones.
>
> jeff
>
> Jason Zurawski wrote:
> > Maxim and Jeff;
> >
> > For clarification, could one (or perhaps both) of you propose a new way
> > forward.  Something small and simple is good enough to kick this
> > discussion off.
> >
> > -jason
> >
> > > >  Hello ( mostly schema and protocol people),
> > > > While working on psPS framework API I found that according to the
> > > > current schema
> > > > definition its very inconvenient to send select:parameter with some
> > > > time range select values.
> > > > For some reasons there is a time schema but there is no support for
> > > > time elements in
> > > > the select parameter.   So, people basically using something like
> > > > <parameter name="startTime">... instead of normal time element. Its
> > > > very strange to have  several ways to treat such thing as time. As
> > > > the simplest approach and may be the easiest step I would suggest to
> > > > allow current time   element as subelement of parameter. Of course I
> > > > can support it for my service ( pinger MA)
> > > > at any time but this feature will benefit every other service as well.
> > > I am planning to support nmtime objects as sub-elements of parameter
> > > elements for the owamp/bwctl (perfSONOBOUY) MA. (I have been unhappy
> > > with the current treatment of time - and have been for a while. Search
> > > the archives for details.)
> > >
> > > I agree that if all services were using the nmtime element, then an
> > > implementation that understood how to decode the nmtime element could
> > > be shared across multiple services.
> > >
> > > Of course, this would represent a major protocol change for any
> > > existing services and it would therefore need a fair amount of time to
> > > make its way into already deployed services.
> > >
> > > Lets at least make sure that you and I are implementing this using the
> > > same schema (syntax) - then perhaps we can convince other services to
> > > adopt it in the future to make coding clients and servers easier with
> > > regard to this often used concept.
> > >
> > > jeff