perfsonar development work

["Jeff W. Boote" <>]

ulisses wrote:
> Hi all
>
> After doing by mistake an rm *.xml, I have redone it roughtly again.
>
> Please tell me if the following is wrong or not, I attach the following 
> messages to be exchanged:
>
> + Full database 
>
>         ---> TOPSDownloadDBRequest
>         <--- TOPSDownloadDBResponse
>
> + Partial database download of nodes
>
>         ---> TopsDownloadNodesRequest
>         <--- TopsDownloadNodesResponse
>
> once these are clear I will make the rest. Please see the comments on the 
> headers.

You are very much missing the spirit of the schema.

The message 'type' should be something very general. It is actually very 
unlikely that you should be creating your own message type. There are already 
some defined for the MA that should be usable for your purpose. 
(SetupDataRequest and MetadataKeyRequest)

To indicate if you want the 'full db' or just some specific set of nodes, you 
should be using the EventType of the metadata. And, you should be using the 
parameters of the metadata to indicate things like time ranges. In fact, for 
that specific case you should probably be making use of the already existing 
'Select' event type and chaining two metadata together to ask for it. Something 
like:

<nmwg:message type="SetupDataRequest" id="m1">
    <nmwg:metadata id="topo1">
        <nmwg:eventType>fullDB</nmwg:eventType>

        <fulldb:subject id="baseDBid" />

        <!-- Just a guess at possible database specific parameters. -->
        <fulldb:parameters id="fdbparam1">
            <nmwg:parameter name="AS">1101</nmwg:parameter>
        </fulldb:parameters>
    </nmwg:metadata>

    <nmwg:metadata id="select1">
        <nmwg:eventType>select</nmwg:eventType>

        <!-- filter chaining to indicate 'selection' range requested -->
        <!-- ref indicates 'basis' for this selection -->
        <select:subject id="selsubj1" metadataIdRef="topo1" />

        <select:parameters id="selparam1">
            <nmwg:parameter name="startTime">1119312000</nmwg:parameter>
            <nmwg:parameter name="endTime">1119830400</nmwg:parameter>
        </select:parameters>
    </nmwg:metadata>

    <!-- trigger to indicate what 'chain' of metadata to use for request -->
    <nmwg:data id="data1" metadataIdRef="select1">
</nmwg:message>

The 'node' request would be very similar. You would modify the first metadata to 
indicate a different event type. This one for a node retrieval. And, then the 
parameters would be specific to that.

To be honest, I think you could probably even use the same event type for these 
two and just indicate different parameters for the selection of all or specific 
nodes... But, since I don't fully understand your database I can't be sure.

> I would prefer to talk about this by phone. My telephone number is +34 
> 912127625, ext 5534

I think it is probably about time for a conference call with all the developers. 
I'll propose one in another email. Each of us has different specialties. One on 
one calls might help initially, but I think a more full group call would be more 
appropriate. You seem to be having trouble with more than one area. (Plus we 
have added a couple more developers, so it is a good time to get them involved.)

You keep presenting different ways to solve the problem, but without us knowing 
what problem you are trying to solve it is difficult for us to suggest things 
and know if they are appropriate.

> the following question arise:
>
> - Do responses must to share a key or identifier in the response that 
> reference the request?

What is shared is completely up to the service. If you support a 
MetadataKeyRequest message, then it would of course be expected that you would 
return keys.

What is definitely expected is that you share metadata along with the data that 
describes the 'common' parts of the data. For example, given the request I 
suggest above, the response should have those two metadata in it. With a full 
set of parameters fully describing the data that is returned.

Have you looked at the example requests/responses in the schema directory?

jeff