perfsonar development work

[Jason Zurawski <>]

Nicolas & All;

See answers to specific questions below...

> Roman reminded us that there were some changes that are not backward
> compatible that need introducing in the schema.
>
> Could you please look at them (two, see below) and tell us the impacts
> they have on your development? (Is it a big/medium/small change) for
> this Friday.
>
> We are evaluating to introduce them in 3.0. (the visualisation need to
> cope with both type of messages, the functional test only with the new
> one - correct?).
>
> Cheers,
> Nicolas
>
>
> -------- Original Message --------
>
> [snip]
>
>>> before 2.3 release I introduced mentioned changes after the
>>> discussion on schema with I2 guys and I hoped to have them in that
>>> release. Then you asked me not to include them because of backward
>>> compatibility issue. I remember that we stated that the changes
>>> would be introduced later (now we preparing 3.0). That is why I'm
>>> asking you to confirm the use of those changes (I need the answer to
>>> know should I update the documentation).
>>
>> Hi Roman,
>>
>> can you please describe those changes
>
> 1) use of eventType element instead of parameter 'supportedEventType'
>
> example:
>
>    <nmwg:metadata id="meta1">
>        <netutil:subject id="subj1">
>            <nmwgt:interface>
>                <nmwgt:hostName>test-hostName</nmwgt:hostName>
>                <nmwgt:ifAddress type="ipv4">10.1.2.3</nmwgt:ifAddress>
>                <nmwgt:ifName>test-0</nmwgt:ifName>
>                <nmwgt:ifDescription>test
> descripyion</nmwgt:ifDescription>
>                <nmwgt:direction>in</nmwgt:direction>
>                <nmwgt:authRealm>TestRealm</nmwgt:authRealm>
>                <nmwgt:capacity>1000BaseT</nmwgt:capacity>
>            </nmwgt:interface>
>        </netutil:subject>
>        <nmwg:parameters>
>            <nmwg:parameter
> name="supportedEventType">http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:parameter>
>
>        </nmwg:parameters>
>        <!--
> <nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType>
>
> -->
>    </nmwg:metadata>
>
>  (commented line is that new thing which replaces parameter)
>
>
> 2) use of netutil namespace (related with eventType value) instead of
> nmwg for datum element in response
>
> example with nmwg namespace:
>
>    <nmwg:data id="d2" metadataIdRef="m2">
>        <nmwg:datum timeType="unix" timeValue="1186735500"
> value="7999.161468670205" valueUnits="Bps"/>
>        ....
>    </nmwg:data>
>
> example with netutil namespace:
>
>    <nmwg:data id="d2" metadataIdRef="m2">
>        <netutil:datum timeType="unix" timeValue="1186735500"
> value="7999.161468670205" valueUnits="Bps"/>
>        ....
>    </nmwg:data>
>> and the impact on the visualisations (changed needed)?
> It's the question to people who work on this.
>
> I'd like to stress that the mentioned changes is not my personal
> initiative (don't worry; it's not again new thing from my side :) Some
> time ago (before v. 2.3) I had the discussion with Jason and Jeff and
> those 2 things were discussed (I think they use them in their
> implementation but I didn't check it)


We currently support both eventType approaches (supportedEventType
parameters and eventType elements) and probably will for some time to
ensure that legacy clients can use the service without issue.

The specific vs nmwg namespace on datum is also in a dual mode right now
(again for legacy client reasons).  The default operation mode is to
return nmwg: formated datum elements.  An 'enhanced' mode can be
triggered currently using a message level parameter:

<nmwg:message>

  <nmwg:parameters>
    <nmwg:parameter
name="eventNameSpaceSynchronization">true</nmwg:parameter>
  </nmwg:parameters>

  <!-- ... -->
</nmwg:message>

This will not be a permanent solution, but is in use currently by some
of our client applications.

-jason