perfsonar development work

["Jeff W. Boote" <>]

Roman Lapacz wrote:
> Please, show me an example of such response (metadata + metadata with 
> key + data). I just want to see how the elements are linked.

Sigh, I just spent the last hour and a half looking for how this was done. It 
seems that it is fairly hard to find old code in svn if you are not sure exactly 
what date range it existed in. (It could be the cvs/svn translation is causing 
issues here too...) I'm even beginning to wonder if perhaps I had it in an 
experimental branch, and not in HEAD.

My best recollection is that the SetupDataRequest message handler did the 
following:

If given regular metadata and not key's:
	It would make the key request. The response would have the keys in the 'data' - 
with the metadataIdRef's of the data element pointing to the associated 
metadata. It would create new metadata objects to hold each 'key' - pulling them 
out of each 'data'. It would set the metadataIdRef of the newly created metadata 
(the one holding the key) to the same id that the 'data' element is 
referencing.* (I am fairly sure it used 'merge' chaining, not 'filter' chaining 
- but not 100%.)

If given key metadata - this whole logic was skipped and the key metadata was 
passed directly to the service engine and it was expected that the service 
engine would maintain the mapping from data to key-metadata.

* To be honest, I don't remember if it added that mapping before or after 
actually fetching the data. I suspect it did it after - so that the service 
engine did not have to worry about it. As I recall the service engine expected 
only very specific chaining - and this probably would have broken that.

It actually occurs to me that there might be a better way to deal with this. I 
don't know if the schema would support this, but the key is supposed to simply 
be a 'private' version of the metadata - right? Why not put the key and the 
subj/parameters in the SAME metadata for this? (Just a half-baked idea at the 
moment, but it might be more simple than using chaining. I have not thought this 
through - but it does sound more simple. We would need to check how the schema 
is currently specified, I think it might be specified such that a metadata can 
hold either a Key, or a Metadata - but not both.)

jeff

XML example of a request and response using chaining (just my best recollection, 
I'm sorry but I can't spend more time looking for this):

<nmwg:message id="req1" type="SetupDataRequest"
        ${namespaces}>

   <nmwg:metadata id="m1">
      <netutil:subject>
         <nmwgt:interface>
             <nmwgt:ifAddress type="ipv4">192.168.1.1</nmwgt:ifAddress>
         </nmwgt:interface>
      </netutil:subject>
      <nmwg:eventType>utilization</nmwg:eventType>
      <nmwg:parameters>${parameters}</nmwg:parameters>
   </nmwg:metadata>

   <nmwg:data id="d1" metadataIdRef="m1"/>
</nmwg:message>

<nmwg:message id="resp1" type="SetupDataResponse"
        ${namespaces}>

   <nmwg:metadata id="m1">
      <netutil:subject>
         <nmwgt:interface>
             <nmwgt:ifAddress type="ipv4">192.168.1.1</nmwgt:ifAddress>
         </nmwgt:interface>
      </netutil:subject>
      <nmwg:eventType>utilization</nmwg:eventType>
      <nmwg:parameters>${parameters}</nmwg:parameters>
   </nmwg:metadata>

   <nmwg:metadata id="k1" metadataIdRef="m1">
      <nmwg:key>
         <nmwg:parameters>${parameters}</nmwg:parameters>
      </nmwg:key>
   </nmwg:metadata>

   <nmwg:data id="d1" metadataIdRef="k1">
      <nmwg:datum value="141231" timeValue="1106492081" timeType="unix" />
   </nmwg:data>
</nmwg:message>