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

DICOM listen library API #1184

Open
SimonBiggs opened this issue Nov 13, 2020 · 0 comments
Open

DICOM listen library API #1184

SimonBiggs opened this issue Nov 13, 2020 · 0 comments
Assignees

Comments

@SimonBiggs
Copy link
Member

If someone wants to start an SCP from within their own application, they need to be able to access that programmatically. They would probably also want to be able to stop the SCP, but that could also just be assumed to take place when the application shut down, so it isn't necessary for a minimum viable API.
Consider an application that has been architected to operate on DICOM data that is on it's local file system.
It doesn't have an SCP, but it's already using PyMedPhys. So... while the user is running the application, they start up a local SCP. And then through other means, they transmit DICOM data to the local SCP. They don't necessarily want people transmitting stuff to their system otherwise (so they don't run it in the background all the time when they aren't using the previously mentioned application).

But frankly, I was thinking that the CLI front end for PyMedPhys would go through the front door (public access to listen_cli). It might be necessary to expose init, for this approach, or perhaps there are other things I've missed or would need to be done differently as well.

However, if the intent is to have the PyMedPhys CLI access DicomListener through a direct import, then just deleting the line above is fine. I've taken to being careful about direct imports because @SimonBiggs has a fair amount of magic going on involving dynamic import to allow delivery of PyMedPhys without packages that aren't used at runtime for individual scenarios. I try to take the approach of keeping as many functions private to a module as possible (because I use a docstring generator plug-in, I have taken to starting with them as public while I'm working locally, until I'm reasonably happy with what I have, and add docstring, then I rename with _ prefix to make most functions private, retaining the docstring so the next time I go through the module I've got breadcrumbs even for the private functions). Relying on private functions, even internally, breaks encapsulation, and that makes for ripple if you decide to refactor if someone (including yourself) uses alot of the private functions instead of having worked on a clean API.

One can certainly treat minimising API for programmatic access as a separate issue and PR.
No one has started programming against DicomListener yet.

Originally posted by @sjswerdloff in #1183 (comment)

@SimonBiggs SimonBiggs changed the title If someone wants to start an SCP from within their own application, they need to be able to access that programmatically. They would probably also want to be able to stop the SCP, but that could also just be assumed to take place when the application shut down, so it isn't necessary for a minimum viable API. DICOM listen library API Nov 13, 2020
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