perfsonar development work

["Jeff W. Boote" <>]

Loukik Kudarimoti wrote:
> > I had similar concerns :) but I was asked by Loukik to do it (before 
> > the change there was no datum in the response). If I understood 
> > correctly, the visualization application made by JRA4 guys requires 
> > this approach. I'm sure Loukik can say more.
>
> As I mentioned to Roman, I certainly don't have a strong opinion on this 
> topic. I don't see how one is better than the other. It is true that in 
> the current scenario the JRA4 visualization tool fails to show that 
> there is no data. Instead it 'crashes' for a particular domain by 
> showing long and 'not-so-easy-to-read' error messages.
>
> One could argue that the change should be made on the JRA4 side and I 
> would also agree to that as well. I think defining a generic datum 
> element (and not really a result code) for such situations would be 
> useful. It will be better than a result code because the result code 
> structure currently does not pass back any metadata (related to the 
> link/network element for example). So, with a datum element which means 
> 'no data' you could say, this particular link (metadata) does not have 
> any data.

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