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

AXL Create function signature #5

Open
gonsie opened this issue Feb 23, 2018 · 2 comments
Open

AXL Create function signature #5

gonsie opened this issue Feb 23, 2018 · 2 comments

Comments

@gonsie
Copy link
Member

gonsie commented Feb 23, 2018

What is the best way to design the AXL API w.r.t. getting the transfer type from the caller.

Currently we take a string and AXL does the conversion axl_xfer_t type.

Should we change this so that AXL Create takes in an axl_xfer_t parameter instead?

Pro:

  • simpler api
  • the enum provides the set of xfer options
  • matches how other tools work

Cons:

  • as the API develops, the enum will change, possibly making incompatibility issues. We could avoid this by only appending to the enum, but this may lead to a bunch of cruft for xfer types that are no longer supported. Otherwise, users will have to recompile for what would be ABI compatible versions.
@gonsie
Copy link
Member Author

gonsie commented Feb 23, 2018

@becker33 says:

Changing the enum would thus be a new major version in AXL... which will be true. It represents either new technology support or deprecation.
No user should try to use a new version of a library without recompiling. Some people do this, but that's wrong.

@becker33
Copy link
Collaborator

In addition to what I said above:

  • a typo in a string is a runtime error and a typo in an enum is a compile time error.
  • We can maintain the gap in an enum if we delete an entry (by manually specifying the gap) so there will not be a recompiling issue for those who are wrong and want to swap in libraries without recompiling.

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