perfsonar development work

[Loukik Kudarimoti <>]

Hi Roman,

I agree with you that the release management has to track changes made 
to schemas/protocols and web service functionality. I believe this is 
something that we have already started doing. This is how:

Major release - If changes are made to web services such that it results 
in backwards-incompatible schema/protocol changes, then such changes 
have to be grouped together and delivered as a major release of 
perfSONAR bundle. This is also the case when major functionality changes 
are made which might not be seen as backwards-incompatible schema 
changes. (example: Authentication feature is introduced).

Updates - If there are some changes that do not cause 
backwards-incompatible schema changes (example: bug fixes or 
enhancements to existing release), such changes are grouped together 
into minor updates to the perfSONAR bundle.

In both cases, the release management will work with the development 
teams to track changes and decide how to deliver these changes.


However, what I think is beyond the scope of release management process 
is to actually control the schema definitions, schema versions and how 
these schemas are used by web services. This has to be done at the 
development level and should be done across all developments to ensure 
similarity.

Loukik.


Roman Lapacz wrote:
> In my previous email I just wanted to express my feeling that the 
> release team should (somehow) keep an eye on the schema and track the 
> changes.
>
> Roman
>
>
>
> Jeff W. Boote wrote:
> > A solution to this has been proposed several times. Full URI 
> > eventTypes have version numbers in them - this is how metadata are 
> > versioned. Different versions of eventTypes will support different 
> > collections of parameters and datum.
> >
> > Additionally, MessageTypes's should be done using full URI's. Then 
> > the message itself will contain a version number.
> >
> > These two things should fully specify the
> > We are working with an extensible schema. Have an over-arching 
> > version does not really make sense. But, we can indicate versions for 
> > specific components. (And do) The trick is to determine what versions 
> > are supported by what services/clients.
> >
> > It occurs to me, that services should probably also register a list 
> > of supportedMessageTypes to the LS...
> >
> > jeff
> >
> > Roman Lapacz wrote:
> > > ... that is why the release team should consider to start the work 
> > > on versioning the schema (or protocol)
> > >
> > > Roman
> > >
> > >
> > > -------- Original Message --------
> > > Subject:     Re: [pS-dev] Proposal of change in Lookup Info structure
> > > Date:     Tue, 10 Jul 2007 13:05:27 +0300
> > > From:     Nina Jeliazkova 
> > > <>
> > > Reply-To:     Nina Jeliazkova 
> > > <>
> > > To:     Maciej Glowiak <>, "Nina Jeliazkova" 
> > > <>
> > > CC:     Verena Venus <>, Jeff W. Boote 
> > > <>, Perfsonar Development 
> > > <>, Jason Zurawski 
> > > <>, Martin Swany <>, Roman 
> > > Lapacz <>, Szymon Trocha 
> > > <>
> > > References:     <> 
> > > <> <> 
> > > <> <> 
> > > <> <>
> > >
> > >
> > >
> > > Maciej Glowiak 
> > > <>
> > >  wrote:
> > >
> > > > Nina Jeliazkova wrote:
> > > > > Hi all,
> > > > > > Initially, I had no preferences in either ot the proposals, 
> > > > what worries
> > > me
> > > > a
> > > > > bit is the ability of introducing new options/parameters without 
> > > > formally
> > > > > changing the schema. > > While it seems to facilitate the work of 
> > > > service developers, IMHO it is
> > > not
> > > > > quite the same for the client. The client will still need to be 
> > > > modified
> > > in
> > > > > order to reflect the semantics of those parameters, resulting in 
> > > > clients
> > > > > declaring support for schema X, but possible interpreting messages
> > > > > differently. If it is OK for other developers, please ignore my 
> > > > comments.
> > > >
> > > >
> > > > Nina, please correct me if I understood you wrong.
> > > >
> > > > My intention was to just change the syntax of Lookup Information. 
> > > > Of course client apps will need to be changed, but the change 
> > > > shouldn't be so big - it's just different structure. Instead of 
> > > > looking for e.g. service name in 
> > > > metadata/subject/service/serviceName you will need to check 
> > > > metadata/parameters/parameter[@name='serviceName'].
> > > >
> > > > Of course for some time there may be problem with various versions 
> > > > of lookup info, but LS may do the translation from old structure 
> > > > and store new values as parameters.
> > > >
> > > > Most of developers using LS registration use generic component for 
> > > > registration, so the change will also be in one place and will be 
> > > > transparent for them.
> > > >
> > > > Maciej
> > >
> > > Maciej,
> > >
> > > Yes, I understand this will be a slight change in the query. The 
> > > problem I am
> > > thinking about is having those changes labeled as the same schema 
> > > version - in
> > > this case how a client that needs to support multiple versions will 
> > > guess
> > > there are differences? If it is not the case, your proposal is fine 
> > > for me.
> > >
> > > Regards,
> > > Nina