perfsonar development work

[Roman Lapacz <>]

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

Good idea. Also it would be good to find some time to discuss 
transformation stuff in Brasil (I won't be there but I'm sure people 
will be interested. Face-to -face meeting might give a real progress). 
Next week I won't be available but I will come back to this topic.

> > > 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).

Lookup information, fetched directly from the service or LS
> 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 would say yes if the question was simpler for me :) Could you make it 
simpler (sorry).

> > > 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?

Could you show example metadata you are thinking of? Use simple time 
conversion unix->iso.


Roman


> > 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