perfsonar development work

[Roman Lapacz <>]

Jason Zurawski wrote:
> Jeff;
>
> > Jason Zurawski wrote:
> > > > 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.
> > >
> > > So the issue still remains of what to do for 'display' of values 
> > > (not necessarily the same as the time that will be used in the 
> > > select statement).  I still believe that this is best in a separate 
> > > parameter block, and as Roman pointed out this couldn't be in the 
> > > same md block currently.  I would propose some sort of additional 
> > > filter chaining as well (although I still think we need to abuse the 
> > > notion of timeType a little further, since this is more of a 
> > > presentation element than a time value):
> >
> > So, perhaps I was not clear enough. 
>
> Actually you were now that I read it again (and recall our 
> conversation about it), my mistake.  Taking this into account my 
> previous example is moot (and your correction as well Roman?

Right. I started this discussion because I felt in my gut that there 
might be a better solution than just adding new parameter as I described 
in m my first email.

> > What I intended to indicate in my #4 is that I don't think 'display' 
> > information should be in the message at all. It is easy enough for 
> > the client to do this time format conversion. And, if it important to 
> > have formats that only present time in a specific format - then we 
> > create a complete new eventType namespace for this more strict 
> > representation. Then you can request the new eventType namespace from 
> > a transformation service that understands where it can get the 
> > 'native' format from.

Yes, a transformation service could be used to transform the format of 
timestamps but adding this functionality to MA should not be difficult 
and will limit the communication between services. I know it's risky to 
say this way because you may think that I tend to group functionalities 
of separate services in one service. It's not my intention. But I think 
sometimes we can be ...(hmm, how to say it)... flexible and adding such 
small thing (but useful) to MA will not corrupt our understanding of pS 
idea behind services.

But on the other hand leaving time conversion to the transformation 
service would simplify MA service implementation.


Roman