perfsonar development work

[maxim <>]

Thanks for comments, Jeff, 
The funny thing is that anyElement can be the subelement of parameter so
its more like protocol thing ( where schema is fine). I am supporting the 
current way of selecting time
range but I can support both. If someone can support for this feature into  
the protocols
"Black Book" then I hope eventually most of the services will support it.
--Maxim

> -----Original Message-----
> From: Jeff W. Boote 
> [mailto:]
>  
> Sent: Thursday, December 06, 2007 5:12 PM
> To: maxim
> Cc: 
> 
> Subject: Re: [pS-dev] treating the time right in the schema
> 
> maxim wrote:
> >  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
>