perfsonar development work

[Maciej Glowiak <>]

>>   
> Well, the solution I gave is enough (see the other email). But I don't
> really see how that change actually requires developers to modify their
> services. Right now, if you have multiple eventTypes inside a message,
> the eventType considered is the last one that is parsed (i.e. it doesn't
> outputs that it doesn't support multiple eventTypes, it just gets a
> random one as valid). This is exactly the same as getAnyEventType you
> mentioned above (but you wouldn't need to change the name, it can still
> be getEventType() and then it wouldn't break code). Only thing that
> needs to change is perfsonar-base and the generic LS Registration code
> to use the new method (other services can change their code _if_  they
> want to have the new functionality for some reason).
> 
> But of course, since 3.1 is already here, and the solution I mentioned
> solves it, there's no need to do it right now...

Ok, I see.

The solution is fine and should work, but that's only getting the
eventType. What about setting it? Somebody might have used "replacing"
of eventTypes just by setting it again. Won't it add second eventType now?

For sure I will have such problem for the multiple parameters for the
same name (similar problem). I use such replacement in my code. I can't
say for sure for eventTypes, because there is a lot of code to be
checked. So that we don't want to do it just before the final release
candidates...

I've already implemneted multiple eventTypes and multiple parameters
with the same name in summary: namespace - but only for hLS/gLS.

Best regards
Maciej

-- 

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

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