perfsonar development work

["Jeff W. Boote" <>]

Uros Juvan wrote:
> What about changing the way Parameters class stores parameters to it's 
> HashMap. Not just as HashMap<String, String>, but as HashMap<String, 
> String[]>.
> We can make this compatible with classes using this class, by returning 
> String[0] on call to existing methods, and adding extra method for 
> returning array of String's.

I believe allowing complex types to be the values of parameters is the best 
long-term solution for the XML side of this.

For parameters that happen to use an array of String values as their complex 
type, this could easily map to what you suggest inside the Java.

Basically, the problem comes down to one of semantics. Does using the same 
parameter name imply an over-write, or concatenation? Think of the case where 
you are using merge-chaining of metadata (like in the rrd config file). The 
meaning might not be as clear...

jeff

> Roman Lapacz wrote:
> > Martin Swany wrote:
> > > Hi Roman,
> > >
> > > > Jason, could you take look at this? What's your opinion on this? 
> > > > Others?
> > >
> > > We had a assumed that they parameter names would be unique
> > > so that we could use the HashMap. To me, this argues for a
> > > "complex" parameter (that is not just a string.) 
> >
> > I believe that such new approach to parameters could be useful also in 
> > other situations.
> >
> >
> > Roman
> >
> > > Then, the parameter
> > > could be a SupportedEventTypes or something similar.
> > >
> > > best,
> > > martin
>
> Regards,