perfsonar development work

["Jeff W. Boote" <>]

Jason Zurawski wrote:
> > > I still am confused as to why you feel 'supportedEventType' 
> > > parameters are a much better fit than eventType in this case, they 
> > > are describing the same exact thing except that eventType is more 
> > > direct than a parameters block.  The old style may have filled a need 
> > > during the early development, but if we are going to progress to 
> > > supporting multiple metrics using the same descriptions we should try 
> > > more concrete solutions instead of workarounds.
> > I would prefer to keep parameters to group supported event types 
> > (first we had eventType element but after a while we decided to switch 
> > to parameters as grouping solution) but I'm not against to come back 
> > to eventType.
>
>
> If it makes the short term work easier than its ok, but we should 
> consider moving to something more formal.

I like using the eventType better. I would prefer to keep parameters for things 
that are not 'always' needed. They are the mutable part. eventType is always 
needed. (And, by extension - supportedEventType would always be needed if it 
were done that way.)

> > > > > > 6) 
> > > > > > http://anonsvn.internet2.edu/svn/nmwg/branches/snmp/example_instances/errors/MDKRequest2.xml 
> > > > > >
> > > > > >
> > > > > > Parameters in the key in metadata m3 represent more than one 
> > > > > > namespace so it should look like this:
> > > > > >
> > > > > >    <nmwg:key id="1">
> > > > > >      <nmwg:parameters id="1">
> > > > > >        <nmwg:parameter 
> > > > > > name="supportedEventType">http://ggf.org/ns/nmwg/characteristic/errors/2.0</nmwg:parameter> 
> > > > > >
> > > > > >        <nmwg:parameter name="type">rrd</nmwg:parameter>
> > > > > >        <nmwg:parameter name="valueUnits">Eps</nmwg:parameter>   
> > > > > >        <nmwg:parameter 
> > > > > > name="file">/home/jason/perfSONAR-PS/MP/SNMP/mead.rrd</nmwg:parameter> 
> > > > > >
> > > > > >        <nmwg:parameter 
> > > > > > name="dataSource">eth0-ifInErrors</nmwg:parameter>
> > > > > >      <nmwg:parameters id="2">
> > > > > >      <select:parameters id="2">
> > > > > >        <nmwg:parameter name="startTime" value="N-50" />
> > > > > >        <nmwg:parameter name="endTime" value="N" />
> > > > > >        <nmwg:parameter name="resolution" value="1" />
> > > > > >        <nmwg:parameter name="consolidationFunction" 
> > > > > > value="AVERAGE" />           </select:parameters>
> > > > > >    </nmwg:key>
> > > > > >
> > > > > > This approach should be used in requests and responses.
> > > > > This is too cumbersome and allowing multiple parameters blocks 
> > > > > doesn't look correct in this case.  We really should use a chain to 
> > > > > describe what is going on, or because the contents of the key is 
> > > > > opaque it should not matter what namespace is used to describe the 
> > > > > internals.
> > > > I think it's quite clear and straightforward. Right, what's inside 
> > > > does not matter for a client but for a service might be interesting 
> > > > and needed not to lose context of parameters. Having all parameters 
> > > > in one namespace nmwg, which in fact might be wrong for some of 
> > > > them, is losing some information.
> > > There is no information loss because the key has been 'cooked' in one 
> > > of its previous visits and the server has organized the information 
> > > in a format it likes, including extra parameters blocks in various 
> > > namespaces really only aids humans as they examine the key (which 
> > > they shouldn't do anyway as it is opaque).
> > > Ideally we shouldn't be passing back a clear key where it is obvious 
> > > to see what we have done (the key structure if I recall correctly 
> > > should be used to save state on the server end), we should start 
> > > moving to an obfuscated key that means nothing by sight.
> > I agree with you that the key has no meaning for a client but a 
> > request with key for service side is a different case. Why not to keep 
> > namespaces as originally? It might be useful for RRD MA (at least for 
> > Java implementation). It will not be the rule for all services of 
> > course. Other services might use totally different keys (even without 
> > parameters :) In fact, client app should not generate keys, it should 
> > get it from a service.
>
> I would still *much* rather we go back to including the entire chain in 
> these communications, that way we are guaranteed to not lose anything.  
> If we are going to treat the entire key as opaque, then it really 
> shouldn't matter what is on the inside, although I am still against the 
> idea of including two sets of parameters 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? (your interface docs 
> seem to show everything being in one nmwg:parameters block, if you are 
> changing things please let me know for interop purposes).

I would like to second this desire to maintain the chaining. Part of Jason's 
proposal that I don't think has been highlighted enough yet is that the metadata 
in the response have a reference back to the metadata in the request. This is 
how a client can easily determine which part of their request the given 
data/metadata is responding to. This mapping only works if the chaining from the 
request is reflected back in the response.

Once upon a time, the RRD MA returned the actual metadata from the request (in a 
more filled-out form). Now, it seems to only respond with a single metadata 
holding the key. It is not clear to me how a client is supposed to know what 
this is in response to if more than one data set is requested (since the key 
should be opaque). Since this is obviously working, I must be missing something. :)

jeff