perfsonar development work

[Roman Lapacz <>]

Jeff W. Boote wrote:
> On Feb 10, 2009, at 3:35 AM, Roman Lapacz wrote:
>
> > Jeff W. Boote wrote:
> > > On Feb 9, 2009, at 5:20 AM, Roman Lapacz wrote:
> > > > > You didn't mention loss earlier, but yes this should be there 
> > > > > too.  I will add it.
> > > >
> > > > I just took a look at an example of iperf output :)
> > > >
> > > > > I have no problem adding the 'units' fields, but lets let everyone 
> > > > > weigh in.
> > > >
> > > > OK. Verena, Jeff what's your opinions on this?
> > >
> > > I would prefer not specifying units in the schema. I don't see any 
> > > reason not to require that the units be something specific when 
> > > encoding the data in the schema. But, I'm sure reasonable people 
> > > might disagree with me on this one. (For example, when Verena and I 
> > > worked on the OWD schema, we decided delays would be in seconds. No 
> > > units.)
> > >
> > > If there is some reason different units are useful, like in the case 
> > > with sharing SNMP data, then we should do it. (i.e. lots of existing 
> > > data is already collected and there is no clear winner as to what 
> > > people are using. We don't want to make 'services' transform the 
> > > data unless necessary for performance reasons.) I don't personally 
> > > think that is the case here.
> >
> > Including units fields would be useful for client applications. This 
> > way such information wouldn't have to be statically encoded in the 
> > clients.
>
> You are either encoding the parameter name that indicates the units, 
> or encoding the units directly in the client. There is no free lunch.

You right, the parameter names would have to be encoded but the benefit 
is that you have the flexibility of changing unit names as parameter values.

> Unless we expect the data to be generated in multiple units, and 
> expensive to convert to a canonical representation I don't see the 
> advantage. My goal here is in simplifying the representation for 
> client applications. The fewer permutations of options that they have 
> to look at, the better.

I think we can leave the current schema as it is. If BWCTL MP or Buoy MA 
users/maintainers will see the need to come back to this topic then we 
can discuss it again.


Roman