perfsonar development work

["Michael Bischoff" <>]

> advantages:
> 1) no need to refactor later - even if we change to something *very*
> different in terms of LS distribution hierarchies.
The reduced effort is minimal (imo) while it does tie you down already.

> 2) If you provide feedback and test the API
> to ensure that it really has all the functionality you need, it will make 
> the API better.
> This
> will make it easier for new clients to be written.
>
you can harvest the learned lessons even if the api are differend. And it's a 
bit of a
contradiction if your going to learn from adapting the api to both usecases 
the api will
change and thus the first point doesn't hold.

> Why not let an API deal with it for you? Then we can manage the
> upgrade path as a full perfSONAR project using one mechanism instead of 
> having individual
> clients have to deal with the upgrade issues independently. (Not that there 
> won't be pain,
> but it will be easier if we can assume a common interaction model. It will 
> be very difficult
> to devise upgrade strategies if every client is interacting in a different 
> way.)

I'm not saying we shouldn't have a unified api and I sure think when we are 
using the
permanent solution we should have a perfSONAR wide one. But from our current 
standpoint of
view the time path is dragging on, the client's that do use ls lookup(or 
going to use) is one
or maybe two? (perhaps I got the wrong picture here) And it's open source 
there is nothing
stopping you from learning from the other persons code. you can even see the 
current
workaround api's as proposals for the dls api. It should also improve 
dls(server), as we make
actual use of the ls, and new use cases might arrive.

I'll try to clarify it more later, but I got to run for a bus now.

regards

Michael