perfsonar development work

[Roman Lapacz <>]

Jeff W. Boote wrote:
> Roman Lapacz wrote:
> > Jeff W. Boote wrote:
> >
> > > Roman,
> > >
> > > This change effects the schema format, right?
> >
> >
> > Jeff,
> >
> > No, it doesn't, it's just additional parameter in the key (even you 
> > don't have to add this, in such situation datum in the response will 
> > have 'unknown' value in attribute valueUnits)
>
> I realize it does not represent a change in 'validating' the schema 
> because it is just another parameter. But I still think this 
> represents a change in the 'business logic'. Right? How do we expect 
> writers of clients to figure out how to make requests and interpret 
> responses? Don't we need to document the specific parameters that are 
> understood and what they mean?

You are right. The documentation is needed. It's still missing but at 
least recent deliverables can be useful to get some info about messages.
Also I assume that client developers use test messages and default test 
client to see how the perfSONAR works.

> I think this needs to be documented in a way that it is kept up to 
> date with the current usage in the code.
>
> If you have suggestions of how to do it, I would love to hear it. But, 
> I think it is currently very difficult for client developers to 
> determine what is expected. We need to give them a clear way to 
> understand this.
>
> Unless you have a better idea, my recommendation is that we keep the 
> examples up to date in the schema area. AND that we write some 
> documentation around those examples. I hope that others can keep the 
> documentation part going, but I think it is probably necessary for the 
> primary developers of the services to keep the examples up to date 
> with regard to current usage in the code.

Right. I will update/add missing example messages in the schema area.

Roman

> What do you think?
>
> jeff