You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
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)
The text was updated successfully, but these errors were encountered: