perfsonar development work

["Jeff W. Boote" <>]

Jeff W. Boote wrote:
> 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.

After talking with Jason, I decided I should have put an example in here to show 
what I'm talking about.

So, for the example Roman sent, the response would contain:

 <nmwg:metadata id="meta2select">
   <select:subject id="iusub2" metadataIdRef="meta1"/>
   <select:parameters id="param1">
     <! string start time will be interpreted as UNIX timestamp !>
     <nmwg:parameter name="startTime">1121472000</nmwg:parameter>
     <nmwg:parameter name="endTime">
       <nmtm:time type="UNIX" value="1121904000"/>
     </nmwg:parameter>
     <nmwg:parameter name="consolidationFunction">AVERAGE</nmwg:parameter>
     <nmwg:parameter name="resolution">60</nmwg:parameter>
   </select:parameters>
   <nmwg:eventType>http://ggf.org/ns/nmwg/ops/select/2.0</nmwg:eventType>
 </nmwg:metadata>

1. The timeType parameter would go away completely.
2. Any parameter that is used to specify a time value could be specified using a 
string (like now) but it would have to be a unix timestamp in ascii string format.
3. Any parameter that is used to specify a time value would need to accept a 
nmtm:time element as the value.
4. There would be no way for a client to specify what timeType they want. We 
should create a time element API for creating time elements represented with 
different types.

For example, for the API we could just extend the current Java marshalling 
classes. Specifically, we could have a get methods for retrieving the value in 
the format needed. So, internal to the service for rrd, you would do something like:

// When parsing parameters
// new will take a Time object or String object (string interpreted as UNIX)
Time startTime = new Time(metadata.getParameterByName("startTime"));

// and later rrdTool needs a unix string
String unixStart = startTime.getUnixString();

Clients could use the same API - so there is no reason to convert at the server. 
This keeps the messages simple and does not overly complicate the client. (And, 
if the marshalling classes are modified so we use DOM in some way later - there 
are lots of examples in the O'Rielly XSLT Cookbook of XSLT translations for 
converting data/time formats.)

If we have need of very, very thin clients - we can use transformation services 
to only present data in a specific format with only specific time types etc...

jeff