perfsonar development work

["Jeff W. Boote" <>]

 wrote:
> Author: mac Date: 2006-08-01 10:17:42 -0400 (Tue, 01 Aug 2006) New Revision:
> 1504
>
> Modified: trunk/perfsonar/src/org/perfsonar/commons/messages/Request.java 
> Log: Few changes made.
>
> MH doesn't change anything in output requests unless there are multiple
> responses in one Message. So, if ServiceEngine is run only once for entire
> Message (one data trigger), response message is sent without any changes. If
> SE was run multiple times, then _0, _1, _2 suffixes will be added to metadata
> and data identifiers.

I think this will cause multiple metadata elements that actually refer to the 
same set of information. Especially given the chaining possibilities.

Think about the RRD MA case where you have a single 'base' metadata indicating 
the interface information, and then two others chained to it specifying 
different directions. And two data triggers pointing at these. With this 
solution, the request for the data for that interface will return a minimum of 4 
metadata elements instead of 3. (Could even be more if the service returns all 3 
metadata in each service engine response instead of just the two metadata that 
the data trigger refers to.) The 'base' will not be the same for the two sets of 
data. I think this could be surprising for clients.

That said, I don't have a better solution unless we constrain services to make 
metadata id's unique... Then the message handler could just be holding them in a 
cache and ignore duplicates.

My worry is that a client could easily be counting on determining which data it 
is looking at by seeing which metadata is referenced. From a client perspective, 
I would want to be able to see how different pieces of data related to each 
other in as easy of a way as possible. I think your current solution breaks 
those relationships.

Can anyone think of another solution? (Is it too burdensome to enforce this 
uniqueness requirement?) Is any one else worried about the response data no 
longer having relationship structure maintained?

jeff