perfsonar development work

["Jeff W. Boote" <>]

Roman Lapacz wrote:
> > > If you are fine with transformation namespace, will you add it to the 
> > > ggf implementation?
> > I think before we add this in we should explore a little further what 
> > goes into a transformation, and what the final result would look like 
> > (a response for this request).
>
> Let's see what Jeff or others will say.

I like the idea of a transformation namespace. I do think we should discuss what 
the syntax and semantics of eventTypes in this namesspace should be before 
adding it in.

Roman - for the latest release you had to create some documentation showing the 
rnc file for the messages/eventTypes that were accepted by the service and I 
believe include some text that explained what the valid combinations of syntax 
meant. Right? What if we started creating that document for this - and used it 
to define the business logic we expect from these transformations? (After all, 
you will need that eventually anyway.)

> > Do we want to be strict in which 'typeType' values to accept?
>
> What do you mean here?

Well - in this case your client wants only to see 'unix' formatted timestamps. 
It is also possible that a given service might not support transformations from 
*any* time-type to *any* time-type. It could be that it is only willing to 
support iso or unix for example. I see two problems we need to solve here:

1) How do we let the client know what transformations are available (similar 
problem to letting the client know what interfaces are available from rrd - so 
we should use the same semantics if possible).

2) How do we syntactically make this request? Is there a 'general' way that we 
can articulate this kind of transformation so it will work for things like 
Location (Lat/Lon) as well?

> > I am also unsure about the use of the 'timeType' parameter here.  To 
> > be consistent we may want to use another 'time' object, but I am open 
> > to debate on that.
> I was thinking about this. This parameter is more to specify the type of 
> transformation, not a specific data or series of data. But right, I'm 
> insure here as well.

What if we had a parameter 'transformElementToType' (specific name is not 
important) that behaved as follows:

The value can be any element that has a 'type' attribute, and that type 
attribute is set to the 'type' that is desired. Any other attributes/child 
elements can be set if they further describe how a conversion to this 'type' 
would be made. (For example, for some time representations you might set an 
epoch here.)

The transformation service (or phase of an existing service) would look for all 
elements of the same namespace and convert them to another element of the same 
namespace, but of the type given in the transformElementToType parameter.

Is this too complicated?

> What about two other metadata blocks (meta1, meta2select). Are they fine 
> for you. I could start work at least on this part and assume that the 
> output format is unix by default.

That part seemed reasonable to me.

jeff