perfsonar development work

[Roman Lapacz <>]

Jason Zurawski wrote:
> > Hmm, but a key can represent a chain of metadata. This is my 
> > understanding of a key (something which is just an id; it does not 
> > matter how it looks like; I could imaging that a service could have a 
> > map structure with pairs key - metadata chain ).
>
>
> Thats not entirely true, a cooked key gives you access to the combined 
> effects of the end of a chain of metadata.  The important thing to 
> remember here is that a chain is constructed with an *explicit* 
> ordering to get some specific data (i.e. first grab the entire data 
> set, then run a filter chain on time, then perhaps do a CDF):
>
>
> <nmwg:metadata id="1">
>  <nmwg:key>
>    <nmwg:parameters />
>  </nmwg:key>
> </nmwg:metadata>
>
> <nmwg:metadata id="2">
>  <select:subject metadataIdRef="1"/>
>  <nmwg:eventType />
>  <select:parameters />
> </nmwg:metadata>
>
> <nmwg:metadata id="3">
>  <cdf:subject metadataIdRef="2"/>
>  <nmwg:eventType />
>  <cdf:parameters />
> </nmwg:metadata>
>
> <nmwg:data id="d1" metadataIdRef="3" />
>
>
> Your current cooking procedure should give something like this (?):
>
>
> <nmwg:metadata id="k1">
>  <nmwg:key>
>    <nmwg:parameters />
>    <select:parameters />
>    <cdf:parameters />
>  </nmwg:key>
> </nmwg:metadata>

In my implementation both solutions are possible to use: 1) only a key 
in the request with all parameters (for example: nmwg + select) or 2) a 
chain where the root is a metadata with a key (as you presented in the 
first example above). If the order is important then the latter solution 
should be used. That's right.


This is one of my example request that I use to test java rrd ma:


<nmwg:message id="msg3"
             type="SetupDataRequest"
             
xmlns:netutil="http://ggf.org/ns/nmwg/characteristic/utilization/2.0/";
             xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";
             xmlns:select="http://ggf.org/ns/nmwg/ops/select/2.0/";>

 <nmwg:metadata id="meta1">
   <nmwg:key>
     <nmwg:parameters id="param1">
       <nmwg:parameter 
name="file">/geant2_java-rrd-ma/samples/rrd/test.rrd</nmwg:parameter>
       <nmwg:parameter name="dataSource">bytes</nmwg:parameter>
     </nmwg:parameters>
   </nmwg:key>
 </nmwg:metadata>

 <nmwg:metadata id="meta2">
   <select:subject id="iusub2" metadataIdRef="meta1"/>
   <select:parameters id="param1">
     <nmwg:parameter name="startTime">1121472000</nmwg:parameter>
     <nmwg:parameter name="endTime">1121904000</nmwg:parameter>
     <nmwg:parameter name="consolidationFunction">AVERAGE</nmwg:parameter>
     <nmwg:parameter name="resolution">60</nmwg:parameter>
   </select:parameters>
   <nmwg:eventType>http://ggf.org/ns/nmwg/ops/select/2.0</nmwg:eventType>
 </nmwg:metadata>

 <nmwg:data id="data1" metadataIdRef="meta2"/>

</nmwg:message>


So I'm not against want you prefer but I allow to use also only a key as 
a container for all stuff where the order is not important.


Roman

> My question then becomes, what is the order in which the blocks of 
> parameters are evaluated?  It may make a difference when one is done 
> before the other, it may not.  We should not get stuck in this trap at 
> all, and instead use the entire chain to ensure we doing the right 
> thing (in the eyes of the chain architect).
>
> > > because it is not very natural in my opinion ('cooking' is 'cooking' 
> > > no matter what end result looks like).  Does the RRDMA use the above 
> > > example now?
> >
> > Yes. After the last release I implemented this (before that there was 
> > a discussion about it on the list). I think it's not a big problem 
> > now because the key should be generated be a service and client 
> > should use them as a black box (it does not know what's inside). The 
> > problem  might be on the client side which generates keys (in this 
> > case the client must know inside structure).
>
>
> For now the simple case of dataset+time filter chain will 'work' in a 
> key, but as they get more complex this will not be the case.  I would 
> prefer we consider the effects of this approach to chaining some more 
> (not necessarily before this next deadline) before it comes deeply 
> embedded in the way we manage requests and responses.
>
>
> -jason