perfsonar development work

[Roman Lapacz <>]

Jeff W. Boote wrote:
> Szymon Trocha wrote:
> > Loukik Kudarimoti wrote:
> >
> > [...]
> > > > 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.
> >
> > Hi all,
> >
> > Just to finalize this decision and have common agreement:
> >
> > - for this release nothing change apart from what Roman did
>
> I thought the agreement was to roll back what he did and not use it? 
> So the SQL MA is consistent with the other MA's. (And have JRA-4 fix 
> their client.)

Now (and  for the release) both MAs return empty data element if there 
is no data in the database .

Roman

> > - for next release modification according to one of the above options 
> > to be discussed. We put on on the to-do list for MAs.
>
> Absolutely.
>
> jeff