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

Support for put-logging #13

Open
anjohnson opened this issue Feb 9, 2018 · 5 comments
Open

Support for put-logging #13

anjohnson opened this issue Feb 9, 2018 · 5 comments
Assignees

Comments

@anjohnson
Copy link
Member

I doubt if QSRV makes the necessary calls to support put-logging yet (see the various asTrapWrite* routines in asLib.h for the server API and Benjamin's caPutLog website for the main listener module) but APS would like to be able to use a version of this to log puts that come into an IOC through pvAccess. Not urgent and we'd be willing to help, I'm just filing this as I remember it.

The existing server API was designed for CA and uses the db_access.h version of dbrType though, so may need modifying somewhat.

Tim Mooney's CA Put Recorder synapps module also uses the listener API.

@mdavidsaver mdavidsaver self-assigned this Feb 14, 2018
@mdavidsaver
Copy link
Member

mdavidsaver commented Feb 14, 2018

Usage of asLib in general is missing. Although this isn't strictly a blocker, I haven't done this yet because there is no way for the PDBProvider to see username (or any credentials).

@mdavidsaver
Copy link
Member

As I think about it, supporting read access permission change will be quite complicated in the case of group monitor. So I'm considering only implementing the write access checks and ignoring attempts to make unreadable PVs. I've only ever cared about limiting/logging writes. Thoughts?

@anjohnson
Copy link
Member Author

The ability to do put-logging and write protection should cover our use cases. I doubt if many client developers have considered the case of unreadable PVs anyway.

Thanks. As I said before, it's still a long time from when we'll actually need this.

@mdavidsaver
Copy link
Member

Also relevant is that PVA doesn't (I think) have a mechanism to notify of permissions changes.

@anjohnson
Copy link
Member Author

PVA doesn't (I think) have a mechanism to notify of permissions changes

That seems like it might be more of a problem that we should discuss in the group. The caProvider has one call to each of ca_write_access(channelID) and ca_read_access(channelID) in its getAccessRights() method but nothing dynamic, so I think you're right.

@mdavidsaver mdavidsaver mentioned this issue Mar 27, 2023
21 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants