perfsonar development work

[Maciej Glowiak <>]

Jason Zurawski wrote:
> Maciej;
>
> > > > In the summarizaton example you used a list of event types with the 
> > > > same name. In the current implementation of NMWG all parameter must 
> > > > have unique names. To be honest I followed the same direction in 
> > > > ps-base2...
> > > >
> > > > =======================================================================
> > > > <summary:parameters id="summmary.md.1">
> > > >     <nmwg:parameter
> > > >        name="eventType"
> > > >        
> > > > value="http://ggf.org/ns/nmwg/characteristic/utilization/2.0/"; />
> > > >     <nmwg:parameter
> > > >        name="eventType"
> > > >        value="http://ggf.org/ns/nmwg/characteristic/discards/2.0/"; />
> > > >     <nmwg:parameter
> > > >        name="eventType"
> > > >        value="http://ggf.org/ns/nmwg/characteristic/errors/2.0/"; />
> > > >     <nmwg:parameter
> > > >        name="eventType"
> > > >        value="http://ggf.org/ns/nmwg/tools/snmp/2.0/"; />
> > > > </summary:parameters>
> > > > =======================================================================
> > > >
> > > > Is it intentional or can be done in different way?
> > >
> > > This was intentional and I was under the impression that this was 
> > > fixed some time ago for the 'supportedEventType' parameter.
> > > It is necessary to support these multiple parameters since a single 
> > > LS will no doubt be submitting many eventTypes in each summary (same 
> > > thing will apply for multiple elements of the same name such as the 
> > > network element).  I would much rather take this approach that trying 
> > > something rather arbitrary such as:
> > >
> > > <parameters>
> > >  <parameter name="eventType1">first one</parameter>
> > >  <parameter name="eventType2">second one</parameter>
> > > </parameters>
> > >
> > > If you have an elegant solution please suggest, but I currently don't 
> > > see another way.
> >
> > Hi Jason,
> >
> > I think I will re-implement it in java PsBase2, but will probably 
> > won't do it for base 1, so we can treat it as new feature without 
> > backward compatibility.
>
>
> What do you mean by this, no muliple parameters and instead just have 
> multiple eventTypes (I would prefer it that way, the only reason I stick 
> in supportedEventTypes is for legacy client and servers).

Jason,

I meant that soon we'll be migrating (re-writting much code) to 
perfSONAR base-2 which is under development but Roman is now working on 
moving RRD MA to it. We may easily implement there such improvements as 
multiple parameters or multiple eventTypes if necessary.

For existing services based on current perfSONAR base and current NMWG 
implementation it would be more difficult and time consuming, so in my 
opinion it we should not make an effort to implementing those features 
in current base/nmwg.


> > You're right, using multiple parameters is the simplest way. However 
> > this will impact on LS implementation (timeouts) and perhaps on other 
> > services (MA?), so we need to tell other people about the change.
>
> I am not sure what you mean by timeouts here?

Ah, ok. Metadata "timestamps" which are inside parameters, sorry. Java 
LS is assuming that setting new parameter (timestamp) with the same name 
but different value will cover the old value. If I changed the NMWG 
implementation I should also change the LS code. I cannot speak for 
other services but they might stop working od work strange because of 
similar behaviour. It was just the example, that the simple change in 
schema may cause a lot of bugs...

Maciej


--

 --------------------------------------------------------------------
| Maciej Glowiak        Network Research and Development            ||
| 

     Poznan Supercomputing and Networking Center ||
| (+48 61) 858 2024          -- skype_id: maciej_psnc   GG: 4526858 ||
 ====================================================================