perfsonar development work

[Jeff W.Boote <>]

Hi Slawek,

A few of us have been discussing this and would like some more time to  
think about the implications.

Specifically, one concern is that this might really be another case of  
needing session state in the protocal. (i.e. the ability to do some  
negotiation between the client/service.) If so, this is not too  
different from what will be needed to negotiate a future execute  
schedule or other parameters in the MP case. In which case, from a  
protocol perspective I would want these kinds of things handled in the  
same (or at least similar) way - not as a series of one-off's added  
when each individual developer decides they need this kind of feature.

Do you have some thoughts as to how the method you have suggested  
below would be applicable to other 'negotiation' types of use cases?

One suggestion I have regarding your proposal, is that not enough  
information is returned that is easily machine-par-sable.  
Specifically, you have the upper limit in the human-readable part. But  
not as part of a defined data type that a service could reasonably  
decode and make a different decision without human intervention.

thanks,
jeff

On Jun 25, 2009, at 1:16 AM, Slawomir Trzaszczka wrote:

> Hi all,
>
> I'm working on lookup service. I would like to ask you few questions
> about lsTTL parameter and nmwg message form. I'm implementing lsTTL
> parameter handling by lookup service.
>
> New feature is used when a service wants to register to lookup service
> and send lsTTL parameter.
>
> LsTTL (TTL - time to live) parameter is used when the lookup service
> cleans up old services. Latest Lookup Service implementation uses  
> global
> lsTTL for all services registered in database. In new version, service
> which want to register to lookup service, can send own lsTTL  
> parameter.
> This parameter will be prevented and it will ignore global lsTTL.
>
> Message from service, with lsTTL parameter:
>
> <message type="LSRegisterRequest">
>   <parameters id="parameters.1">
>     <parameter name="lsTTL">300</parameter>
>   </parameters>
>
>   <!-- ... -->
> </message>
>
>
> The problem is how can lookup service inform client that sent lsTTL
> parameter is accepted/rejected(incorrect,out of bound) - in which part
> of nmwg message?
>
> This is my proposal :
>
>
> <nmwg:metadata id="M_E_T_A_1">
>   ...
> </nmwg:metadata>
>
> <nmwg:data id="result-code-description" metadataIdRef="M_E_T_A_1">
>
>   <nmwgr:datum xmlns:nmwgr="http://ggf.org/ns/nmwg/result/2.0/";>
>        Data has been registered with key ...
>   </nmwgr:datum>
>
> </nmwg:data>
>
> <nmwg:metadata id="result-code1">
>      <nmwg:subject id="reference-to-metadata"
> metadataIdRef="M_E_T_A_1"/>
>
>        <nmwg:eventType>
>        http://ggf.org/ns/nmwg/result/2.0/warinig/ls/ttl_out_of_bound
>        </nmwg:eventType>
>
> </nmwg:metadata>
>
> <nmwg:data id="result-code-description1"  metadataIdRef="result- 
> code1">
>      <nmwgr:datum>
>                Miminimal TTL is 90 sec. Your was 80 sec.
>      </nmwgr:datum>
> </nmwg:data>
>
> What do you think about this response ? Is it correct ?
>
> Regards Slawek