perfsonar development work

[Jason Zurawski <>]

Roman;


> > > 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.
>
> Right, but in case of using a key a metadata chain does not have to be 
> included and analyzed in the request because that key represents that 
> chain.


I addressed the issue of chains in the previous e-mail, but I also want 
to comment on the importance of maintaining state again.  Currently we 
don't have way to 'track' the progress of a request or a response.  When 
we start using multiple services for a single request (MA, AA, 
Transformation, etc.) it will be necessary to point to the IDs of 
messages and metadatas from origin sources (clients, etc.), especially 
when another service may have touched or altered the communication in 
some way.


-jason