search

jamsden / oslc-core-test

0 stars 0 forks source link

Bring back the OSLC-Core-Version header as a MUST #14

Closed jamsden closed 5 years ago

jamsden commented 5 years ago

I think not having a version header will make it difficult for the clients to work around incompatible implementations. That will increase the cost of introducing backwards-incompatible changes in the future versions of OSLC.

jamsden commented 5 years ago

From: berezovskyi - James Amsden the only mention of this I managed to find was in the mailing archives from 2015.

jamsden commented 5 years ago

Yes, the decision to not include OSLC-Core-Version=3.0 was done before I joined the TC as I recall. What was odd is that OSLC Core 3.0 at that time was also incompatible with OSLC Core 2.0, at least for Discovery.

But more generally, you are correct, any current or future incompatibilities in an API can be indicated to clients using a version designator. However, the need for such designators because of incompatibilities is something that should be avoided in any public API, let alone one that‘s intended to enable integration.

OSLC has a history from its early conception, to initial experimental specification for 1.0 and then a stable set of 2.0 specifications created by open-services.net. This occurred over a number of years and a lot of IBM and 3rd party integrations became dependent on 1.0 and even more on 2.0. Essentially we thought the business opportunity for an integration API would slip away if we introduced yet another incompatible 3.0 version - the existing tools just wouldn‘t migrate and OSLC 3.0 would be irrelevant. At the same time, the additional business value of LDP and the use of Link headers for discovery was weak - a better technology for sure, but not really any difference in integration capability and therefore difficult to motivate the development costs to migrate, or suffer lost integrations because of incompatibilities.

Introducing OSLC-Core-Version=3.0 would certainly allow clients to easily determine what version of OSLC the server was presenting them. But it wouldn‘t do anything to help them address the incompatibilities that resulted. It‘s avoiding this development work for clients and servers that we were trying to address.

jamsden commented 5 years ago

From: berezovskyi - Thank you, Jim, for offering this extended perspective on the reasoning behind the compatibility considerations. I will begin by saying I am 100% in favour of rejecting any proposals that will break backwards compatibility in OSLC 3. The version header in OSLC 3 will not perform any function whatsoever. And hopefully in OSLC 4 etc. But I want to make sure that the spec editors of OSLC 4+ can consider introducing breaking changes with a clear path for implementation given a sufficient support from the community. Does it make sense?

jamsden commented 5 years ago

Breaking changes are always a possibility with sufficient business and technical motivation and justification. However, in the case of OSLC, I‘m hoping the use of WWW architecture will allow additional capabilities to be added to OSLC without breaking what‘s already there.