perfsonar development work

["Jeff W. Boote" <>]

Jason Zurawski wrote:
> Ulisses;
>
> > >  Is there also a reason as to why the first metadata is blank?  I 
> > > believe that when we designed the schema we envisioned the 
> > > nodes/links/interfaces as being more of a metadata item that could be 
> > > wrapped in data, something like this:
> > >
> > > <nmwg:metadata id="somemetadataid">
> > >  <!-- original request metadata -->
> > > </nmwg:metadata>
> > >     
> >
> >
> > currently, my request is (literally):
> >
> > <nmwg:message type="TOPSDownloadDBRequest"
> >               id="msg2"
> >               xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"; >
> >
> >               <nmwg:metadata id="something"></nmwg:metadata>
> >
> >               <nmwg:data id="something_else" 
> > metadataIdRef="something"/> <!--data trigger-->
> >
> > </nmwg:message>
> >
> > so why should I put inside the metadata element?
> >   
>
>
> And you have explained that this will 'dump' the entire database.  I 
> suppose this is ok for now, but in the long run it will make more sense 
> if we can define *all* interactions that are possible so that the system 
> will be more robust.  I don't see a problem in development if you don't 
> read or handle the metadata element in a special way, but defining what 
> it could possibly be (such as a query for a specific node, or link) is a 
> good idea.
>
> >  
> >
> > > You may have given me the reasons as to why you have chosen this 
> > > design before (I realize that this is more or less just the results 
> > > from a database query), but for my sake (and anyone else who has the 
> > > time to help you) could you please re-state what you are trying to 
> > > accomplish?     
> >
> >
> > - export links which in turn have interfaces
> > - export nodes which have interfaces, but instead of re-define them 
> > again only put
> >   references to interfaces defined in links.
> >
> > just that.
> >
> > now I'm exporting all links within a <data> element and all nodes 
> > within another single data element.
> >
> >   
>
>
> The exporting within the data element is what I (and some others) are 
> concerned with, I suggested something like this (using metadata):
>
> <nmwg:metadata id="meta1">
>   <nmwg:subject id="subid1">              <nmwgtopo3:node id="node1" 
> xmlns:nmwgtopo3="http://ggf.org/ns/nmwg/topology/base/3.0/";>
>       <nmwgtopo3:hostName>landas-gw.uninett.no</nmwgtopo3:hostName>
>       <nmwgtopo3:name>landas-gw.uninett.no</nmwgtopo3:name>
>     </nmwgtopo3:node>
>   </nmwg:subject>
> </nmwg:metadata>
>
> Each node/interface/link was designed to be metadata, and would be 
> returned like this (inside of one larger data block).  This is up for 
> discussion, so that is nice way of saying "everyone else should start to 
> chime in now too" :)

In some ways this seems more similar to the case where the RRD MA returns 'keys' 
in the data elements. Usually, those are used in metadata elements, but because 
of the semantics of the request - they more appropriately fit in the data.

In this case, the request is for 'topology' data. In most uses of the topology 
schema we envisioned, those elements are in the metadata because you are using 
the topology to indicate the subject for the data that is retrieved.

I am not sure, because the expected use cases for this service have not been 
explained enough, but I think that this is a case where the topology IS the 
data. So, it might make sense to return topology elements in the data.

However, there still needs to be a reasonable subject/parameters in the request 
so you can indicate 'what' you want topology about. For example, if the topology 
database is collecting topology from some specific network, or some collection 
of networks you  need to indicate that. The subject could define an AS if you 
want to try and retrieve all topology relating to a specific AS.

jeff