perfsonar development work

["Jeff W. Boote" <>]

On Apr 30, 2008, at 3:54 PM, Michael Bischoff wrote:

> > > It is important to point out that while it will of course be  
> > > possible for pS-UI
> > > to make both queries - the intent was to create a resolver style  
> > > library that abstracts
> > > this into an API. That way the move to dLS would be transparent to  
> > > clients. (If you have
> > > read the dLS document at all - this is discovery phase, then query  
> > > phase. Most common uses
> > > of the LS should not need to explicitly do both.)
>
> I fail to see the need for this added functionality(the api beeing  
> able to do both) is any
> advantage to us. We have full control over the psUI code and as soon  
> as the dls is
> implemented correctly the workaround way of using the current ls as  
> a distributed kind is
> obsolete. We can just replace the code. Also as the actual ls lookup  
> code on the client side
> isn't an entangled part of psUI. I don't see migration problems  
> going to dls even if the api
> is totally different. on the other side I might see the possible  
> restrictions because it
> needs to support some work around and time spend might actually take  
> longer then doing some
> re-factoring in psUI.

advantages:
	1) no need to refactor later - even if we change to something *very*  
different in terms of LS distribution hierarchies.
	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.

> Are the envisioned lookup schematics (of the workaround) documented?  
> if we have nailed down
> the how then perhaps Maciej can handle the server side (ls  
> registering to another ls) given
> to what extend configuring an ls with a lsregistion aux component  
> isn't enough. under the
> current plan. I'm going on a short trip over the weekend, but given  
> we can clear up how we
> want it weshould be able to have a working beta by the end of next  
> week.(it will probably
> take two or three weeks before there are enough deployed ls-es setup  
> for it to actually have
> any use.)

3) Since the envisioned lookup schematics are different in the short- 
term verses the long-term, which one do you want? I guess you are only  
asking about short-term here...

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.)

jeff