perfsonar development work

[Slawomir Trzaszczka <>]

Hi Jeff,

I have no idea about response (with rejected parameter information)
message format. I think that parameter negotiation should be very easy. 

Client send request to  service (e.g. LookupService). Sent message has
parameters (e.g. lsTTL parameter). If the parameters are incorrect,
message will be processed but parameter will be rejected. Response
message will have to contain information about parameters mistake (e.g.
out-of-bound) and information about this parameter limitation (correct
value). If the client will want to send new parameter, he will send
registration message with new (improved) parameter to service. Correct
parameter will be accepted and information about it will be send to the
client (parameter accepted).


thanks, 
Slawek.


On Thu, 2009-07-02 at 10:03 -0600, Jeff W.Boote wrote:
> 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
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>