perfsonar development work

["Jeff W. Boote" <>]

From reading Jason's email, I think that I was perhaps not clear.

I favor only having 'throughput' - I think 'value' is confusing for  
tools that provide multiple types of values.

The question for me is one of backward compatibility. If there are  
clients out there that expect to see the throughput in a 'value'  
attribute, I think we should provide it that way in this version but  
deprecate it. And also provide the exact same data in a throughput  
attribute so that clients can move to the new method.

If we don't have clients to worry about here - then I think we should  
immediately drop 'value'.

jeff

On Feb 6, 2009, at 9:52 AM, Jason Zurawski wrote:

> All;
>
> In the end I dont have a strong opinion either way.  Just note that  
> we do have many legacy pSBs on Knoppix disks that will always report  
> 'throughput'.  If we want future versions to report 'value',  
> 'throughput', or even both I can do that, but for Roman's sake he  
> may need to recognize both for the foreseeable future.
>
> If we want to be consistent with other tools I suppose sticking with  
> value is appropriate, but I feel its less descriptive for something  
> like iperf that does report several 'values' for output.  I am sure  
> there are more tools out there in the same boat, so sticking with  
> the value paradigm just because 'everything else does it' doesn't  
> completely convince me.
>
> -jason
>
>
> > I don't think it is such a good idea to keep both value and  
> > throughput. This complicates clients since they will not know which  
> > one a particular service will use. I can see doing this as part of  
> > a well defined transition plan - for example this version of the  
> > service MUST specify both so that old clients are not broken, and  
> > value is expected to be removed in the next major release.
> > Just letting service use which ever one they want is not nice for  
> > clients. (Or am I mis-understanding?)
> > jeff
> > On Feb 6, 2009, at 6:39 AM, Roman Lapacz wrote:
> > > Verena Venus wrote:
> > > > Hi all,
> > > >
> > > > Am Friday 06 February 2009 14:23:24 schrieb Roman Lapacz:
> > > >
> > > > > Jason Zurawski wrote:
> > > > >
> > > > >
> > > > >
> > > > > Hi Jason,
> > > > >
> > > > >
> > > > > > > The schema does not have 'throughput' or  'jitter' elements.
> > > > > > Corrected in my doc and the iperf schema in the main pS repo.   
> > > > > > Jitter
> > > > > > *should* have been there since this is reported by iperf UDP  
> > > > > > tests.
> > > > > >
> > > > > > Throughput is more descriptive than 'value' in my opinion  
> > > > > > (since there
> > > > > > are many 'values' that can be returned by an iperf test).  I have
> > > > > > added throughput to the schema but kept value for now in case  
> > > > > > VV or
> > > > > > anyone else has a use for it.
> > > > > >
> > > > > > I think we should talk about deprecating the attribute or perhaps
> > > > > > allowing it to stay with a use that will vary by service (I would
> > > > > > prefer the latter).
> > > > > The latter is fine for me as well.
> > > > >
> > > > > I've just created RC1 of Java SQL MA v.2.1.1 with iperf stuff and
> > > > > previous schema. On Monday I will create the new one (RC2) with  
> > > > > your
> > > > > updates (compatibility has hight priority!).
> > > > >
> > > > >
> > > > > Verena, any comments on changes?
> > > > It would be nice, if you could send me the new schemata/examples  
> > > > when everything is settled. I can do the changes then very quickly.
> > >
> > > I will updated the service and message examples and send them to  
> > > you on Monday.
> > >
> > > Roman