perfsonar development work

["Jeff W. Boote" <>]

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>

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