perfsonar development work

[Loukik Kudarimoti <>]

Martin Swany wrote:
> Hi Loukik,
>
> > Martin, you assured us that there weren't any schema changes for us 
> > to worry about. But the changes below clearly alters the schema that 
> > we have agreed with the JRA4 guys to use for lightpath status 
> > monitoring. So, if we continue working with the latest code, our SQL 
> > MA won't be able to talk to JRA4 analysis tools right?
>
> Right, I'm sorry if I was misleading (I was actually
> confused a bit too and I'm afraid that I passed it
> on.)  I apologize for that.
>
> The actual schema file didn't change in a way that
> affected backward compatibility.  The old location
> elements are still there (I believe.  If not, then we
> will roll back.)
Martin, Jason,

For me it looks like the changes were made by Jason which affected both 
the schema and the code i.e

This was what was previously agreed with the JRA4 guys:

<nmtopo3:node xmlns:nmtopo3=http://ggf.org/ns/nmwg/topology/base/3.0/
                            id="node1">
        <nmtopo3:city>Newark</nmtopo3:city>
        <nmtopo3:country>USA</nmtopo3:country>
        <nmtopo3:institution>University of 
Delaware</nmtopo3:institution>    
</nmtopo3:node>

This is the new one:

<nmtopo3:node xmlns:nmtopo3=http://ggf.org/ns/nmwg/topology/base/3.0/
                            id="node1">
        <nmtopo3:location>
              <nmtopo3:city>Newark</nmtopo3:city>
              <nmtopo3:country>USA</nmtopo3:country>
              <nmtopo3:institution>University of 
Delaware</nmtopo3:institution>                
         </nmtopo3:location>           </nmtopo3:node>

The changes above affected the schema and the code. Because of the 
changes to the schema, SQL MA will not be compatible with the JRA4 
lightpath status MP neither the monitoring tool developed by them.

I noticed that Jason made changes to the code which fixed compilation 
problems but I fear that the schema is still changed and these changes 
haven't been discussed/agreed with the JRA4 guys..

Can you please confirm what the case is?

thanks,
Loukik.




> > These improvements are for the good. I agree with them. For me, the 
> > only question is how we bring out these changes (we haven't discussed 
> > it openly) and at what time (we are close to a software release).
>
> My thinking was to add the new functionality while supporting
> the old as well.  We've done that a couple of other places where
> getFoo hides a call to getParameter("Foo") so that everything
> that worked before continued to work.
>
> That was inadvertently broken while adding the new style functionality.
>
> I agree that we need to discuss the final details too.  All that
> happened schema-wise is that the existing elements that
> indicated some information about the location of an object
> are now moved inside a location element so that it can have
> types of location info.  This is really a higher-level change that
> allows us to make changes better.  It is just really unfortunate
> that we broke existing code to do it.
>
> (Again, though, I thought that we were making branches to
> start releases so that development can continue.  When the
> trunk is broken (a natural occurrence no matter how careful
> you are), the offender is called out and things are fixed.)
>
> > Also, is it not possible to use the nmwg base versioning and produce 
> > a different version so that we can continue using the old one for the 
> > purpose of JRA4?
>
> Both the TopS and the JRA4/L2 schema are in the version 3
> framework, so I prefer to operate with the helper functions
> mentioned above.  That means that we have to preserve
> backward compatibility and when we don't, it is a bug (like
> this one.)
>
> best regards,
> martin