Skip to Content.
Sympa Menu

perfsonar-dev - Re: [pS-dev] problem with Node class

Subject: perfsonar development work

List archive

Re: [pS-dev] problem with Node class


Chronological Thread 
  • From: Martin Swany <>
  • To: Loukik Kudarimoti <>
  • Cc: , Roman Lapacz <>, Szymon Trocha <>, Nicolas Simar <>, "" <>
  • Subject: Re: [pS-dev] problem with Node class
  • Date: Mon, 27 Nov 2006 11:50:49 -0500

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.)

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




Archive powered by MHonArc 2.6.16.

Top of Page