perfsonar development work

[Guilherme Fernandes <>]

Maciej Glowiak wrote:
> > >   
> > >       
> > 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...
>
>   
Actually, with "the solution I mentioned solves it" I meant the one of 
using multiple metadata blocks, one for each eventType. It works fine 
for registering multiple eventTypes to the hLS. I agree this shouldn't 
be done right now, before the final RCs (that's exactly what my last 
line said hehe).

But, even though it won't be done right now, since we are discussing 
development options: You can have the eventTypes on a List and any 
single eventType operation be done with the first one in the list. Then 
equals() can be overrided to consider only the value attribute, and 
support direct comparison with a String object, which would enable easy 
searching and can be used to avoid duplicates. But again, my only 
concern here was regarding LS registration (since the multi-LS protocol 
needs this to function properly, and we are already deploying it).

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