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

Additional protocol variable and no duplication of IpAddress and Port variables #27

Closed

Conversation

PTaeuberDS
Copy link
Collaborator

@PTaeuberDS PTaeuberDS commented Jun 16, 2023

This PR removes the duplication of the IpAddress and port variables for the different protocols, but adds another variable to configure the protocol.

@PTaeuberDS
Copy link
Collaborator Author

PTaeuberDS commented Jun 16, 2023

@andreas-junghanns @pmai
@ everybody interested

The PR is ready for review. See discussion in #19.

Copy link
Contributor

@andreas-junghanns andreas-junghanns left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this version somewhat better as this is how I have seen it done in many tools.
However, as @pmai points out: the a2l file is more powerful and we cannot be consistent with it in all cases. At best, we should not contradict the a2l specification. I wish I had a good intuition about what to do here.

@PTaeuberDS PTaeuberDS changed the title Handling Configuration Parameters and other Issues: Variant 2 Alt. 2: Additional protocol variable and no duplication of IpAddress and Port variables Jul 5, 2023
@PTaeuberDS PTaeuberDS force-pushed the resolveIssues_oneProtocolVar branch from 8660eee to ae24da6 Compare July 6, 2023 07:15
@PTaeuberDS PTaeuberDS force-pushed the resolveIssues_oneProtocolVar branch from ae24da6 to b849eeb Compare July 6, 2023 08:29
@PTaeuberDS PTaeuberDS changed the title Alt. 2: Additional protocol variable and no duplication of IpAddress and Port variables Additional protocol variable and no duplication of IpAddress and Port variables Jul 6, 2023
@PTaeuberDS
Copy link
Collaborator Author

After some more digging into this topic I'm now convinced that the current version that allows running two channels in parallel should be the preferred way. Therefore, I close this PR. I will add some more comments in the issue (#19).

@PTaeuberDS PTaeuberDS closed this Jul 25, 2023
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

Successfully merging this pull request may close these issues.

2 participants