perfsonar development work

[Loukik Kudarimoti <>]

Jeff W. Boote wrote:
> In most visualization environments - a 'special-value' like this 
> indicates that the measurement took place, but that it returned an 
> exceptional value. In this case, no measurement took place during that 
> time. This is a different situation. I would prefer to see this 
> different situation indicated in another way. (Otherwise, there is no 
> way to differentiate the case where the measurement did take place - 
> and the value returned is special.)
>
> I personally like the empty data as the way to represent the fact that 
> there is no data. This is not really an error condition - you are 
> getting exactly what you asked for. But, if this is not acceptable. I 
> would prefer to see something like:
>
> 1) A result datum/metadata to indicate this case. I agree with what 
> you say above about not having access to the request md. This could be 
> solved by referencing the request md from the result-md.
>
> 2) A parameter block as a child of the data with parameters indicating 
> things like this. But, I do like the result-code solution much better. 
> That is what the result-codes were created for...
>
> In any of these cases, the JRA-4 vis-tool would need to be modified to 
> understand the semantics. I know they won't like that. But, I do think 
> it is very important that all the MA services behave in a similar 
> fashion here - we should not modify one of the MA's to satisfy a 
> single client. There are several clients... If you change the 
> semantics here - then the other clients will need to be modified to 
> understand these semantics as a special case if they interact with 
> this MA. (And I expect that to happen.)
>
> jeff
Jeff, the point that you make is good. I agree.

At this stage, its better to talk to the JRA4 guys to work on this on 
the client side rather than change the way we are doing things on the 
service side. After this release, we can work on improving the schema to 
make use of one of the options that you suggested (ideally option 1 above).

If we are going for such a change in the future, it doesn't make sense 
to do the change that we are trying to do right now i.e. its better to 
leave the data element with no datum elements inside to represent 
absence of data on the service side. Later on, when we have devised it, 
we will include a special datum (or any other workaround). That sounds 
like a better evolution strategy than what I was previously thinking about.

Roman, could you revert your stable branch back to the previous revision 
when you hadn't made this change? I am really sorry for having changed 
my decision. I will contact the JRA4 guys (for this as well as the 
result code implementation that they haven't taken care of yet).

thanks,
Loukik.