Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Model compatibility #293

Open
demx8as6 opened this issue May 3, 2018 · 6 comments
Open

Model compatibility #293

demx8as6 opened this issue May 3, 2018 · 6 comments

Comments

@demx8as6
Copy link
Collaborator

demx8as6 commented May 3, 2018

Some model compatibility ideas that can be added to a white paper.

Model compatibility.pptx

@italobusi
Copy link

Martin, thanks for the slides. They are useful to show some of the issues that I can see when there is no backward compatibility.

In slide 4, how can the controller software (written today when v1 is available and v2 is not known) detect a new API version and implement the proper translation function (f(x2)=x1)?

@italobusi
Copy link

The solution in slide 5 looks more realistic since the translation between v2 and v1 should be performed by the system implementing the newer version

However, slide 6 highlights some other issues. Please consider that TAPI is planning to deliver a new release every six months so the number of releases for which translation is required in getting higher and higher.

I think that performing translations in sequence my lead to performance issues that needs to be evaluated carefully.

Merging translations means that the systems needs to support a growing number of translators as the number of TAPI releases increase and that these translators needs to be re-written every time a new TAPI release is implemented.

@italobusi
Copy link

Another issue I think we need to evaluate is that translation functions do not provide any feature (no new revenues for the operators) but still requires development efforts and costs.

Who is going to pay the cost of the translators?

@demx8as6
Copy link
Collaborator Author

In slide 4, how can the controller software (written today when v1 is available and v2 is not known) detect a new API version and implement the proper translation function (f(x2)=x1)?

The controller is informed by a "schema-change-notification" or detects in a next "hello-message" a new api version. In order to process it - the new translation must be avalable in advance or could be uploaded on-the-fly from a repository.

@demx8as6
Copy link
Collaborator Author

I think that performing translations in sequence my lead to performance issues that needs to be evaluated carefully.

My personal experience is that the current hard- and software is so powerful, that it is not the main issue. However, it needs to be measured and the addressed if it is an issue - no doubt.

@demx8as6
Copy link
Collaborator Author

Another issue I think we need to evaluate is that translation functions do not provide any feature (no new revenues for the operators) but still requires development efforts and costs.
Who is going to pay the cost of the translators?

I see it different - compatibility is a feature and there is no function for free.
There is no generic answer to this questions. It should be the one who benefits most.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants