TAP Implementation Issues (cont'd)

[Doug Tody]

I should add, obviously it is also possible to have different versions
of services be provided as separate service instances (hence
1.0 and 2.0 might be separate service implementations, registered
independently).  What VERSION adds is the ability to have redundant
(as in safer) runtime version checking at the protocol level, as well
as additional flexibility in having a given service implementation
support multiple versions.  The difference between a 1.1 and a 1.2 for
example might be quite minor, hence much easier to support within a
single implementation and code base.  Even with major version changes
this could well be the case.


On Thu, 22 Oct 2009, Doug Tody wrote:

> On Thu, 22 Oct 2009, Tom McGlynn wrote:
>
>>  One thing that my typo's may have obscured is the issue of upward
>>  compatibility.  There has been a general IVOA statement that version
>>  1.n+1 in somehow compatible with version 1.n.  If I have a client that
>>  is requesting 1.1 but the service only supports 1.2 is that OK?  Or
>>  vice versa?  If no to both, then what do we mean by compatibility between
>>  minor version numbers?  Or are we simply ignoring that precept here?
>>
>>  Regardless the specification does not indicate how a service indicates
>>  which version it supports and I still have no idea what "level two" is.
>>  Are there any SSA services that actually do anything with this or is it
>>  something that seems like a good idea but nobodies actually using?
>
> While this has been addressed somewhat within IVOA (most recently
> witin the documents and standards area I think) I am not sure we have a
> sufficient definition yet of major/minor versions and how to deal with
> finer points such as backwards compatibility.  SSA took a stab at this
> but it is something which really needs a broader treatment within IVOA.
>
> What I think we have so far is that a major version number increase
> ("level 1") e.g., 1.0 to 2.0, indicates that the interfaces are not
> compatible; if the client asks for V2 and the service only does V1
> then it is a protocol mismatch and a hard error.
>
> My preference would be that a minor version number increase ("level
> 2" or x.n+1) would indicate that the new interface is backwards
> compatible.  That is, new functionality or detail has been added
> but the older parts of the interface have not changed.  Hence if the
> client requests version 1.1 and the service implements 1.2 that is ok.
> If the client requests 1.2 but gets 1.1 that is an error as presumably
> the client needs whatever was added in 1.2.
>
> If the client does not specify the interface version then the service
> would default to the highest "standard" version (hopefully the client
> does some other checks or did a proper service selection in advance
> using the version information in the registry, but that is not our
> concern here).  "Highest standard version" seems obvious but the
> issue is if the service supports a newer prototype version as well.
> So for example the most recent standard version is 2.0 but the
> service also provides a prototype of 2.1.  Then the client would get
> 2.0 by default but it could get 2.1 if it explicitly requested it.
> The client is allowed to omit VERSION to disable runtime version
> checking or explicit selection.
>
> This is what I would suggest and what we have been doing with VERSION
> in the DAL interfaces, but I am not sure if it agrees with the
> latest discussions in other areas such as documents and standards.
> Probably, although I am not sure the finer points have yet been
> adequately addressed.
>
> None of this has been used in earnest yet as so far we have few cases
> where multiple protocol versions coexist.  In most cases thus far,
> e.g., for SSA, what we have differs so much that these are considered
> separate service types.
>
> 	- Doug
>
>
>