perfsonar development work

["Michael Bischoff" <>]

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

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

that should also give ppl space to breathe