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

Long-term: support different data sources and prefer them over Channel Access #4

Open
klauer opened this issue Jun 3, 2021 · 3 comments

Comments

@klauer
Copy link
Contributor

klauer commented Jun 3, 2021

Consider moving the primary data source from EPICS Channel Access (CA) to Kafka or (less preferably) PVAccess.

This sort of consistency issue is just non-existent when you have a single data structure containing all the necessary information to decode an image.

Originally posted but modified by @klauer in #3 (comment)

@klauer klauer changed the title Long-term, I wonder if we should consider moving the data source from CA to [Kafka](https://github.com/jwlodek/ADPluginKafka) or less preferably PVA? This sort of consistency issue is just non-existent there. Long-term: support different data sources and prefer them over Channel Access Jun 3, 2021
@ZLLentz
Copy link
Member

ZLLentz commented Jun 3, 2021

How do we handle cross-subnet activity with kafka?
We actually already do have PVA running on most of these

@klauer
Copy link
Contributor Author

klauer commented Jun 3, 2021

Good question. I'm not very knowledgeable about Kafka, but replacing PVAccess with standard protocols where we are able to is, in my opinion, probably a good path forward. I'll ask around out of curiosity.

Fair point that PVA is already deployed - I suppose we should support it regardless.

@ZLLentz
Copy link
Member

ZLLentz commented Jun 3, 2021

Oh I absolutely agree, standard protocols are the way to go where possible. This will make the user experience and the developer experience much better.

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