Acknowledge which query providers list DICOM meta-data

[Enet4]

Indexer plugins exist to serve two key purposes:

1. To make an abstraction over the underlying database technology, thus being able to benchmark different DICOM indexation techniques. Query providers bound to this indexer will have the necessary logic to retrieve DICOM data from such a database.
2. To obtain different interpretations over the DICOM data (e.g. applying CBIR, statistical analysis, ...). Query providers will allows us to retrieve the resulting data (e.g. feature vectors).

With that in mind, we know that some indices will hold DICOM data, while others will not. Only the query providers that hold DICOM should be selected for operations such as retrieving DIM identifiers (StudyInstanceUID, SeriesInstanceUID, SOPInstanceUID), and all DICOM-specific protocols (Q/R, WADO, ...). However, right now there's no way to know where DICOM data is kept. Even if some query providers may understand our Lucene-based queries, they might not give us the intended results, and our DICOM service implementations could (in the worst case) fail against this situation.

The actual request: To have a means in the Dicoogle core to identify which of the query providers are DICOM providers. A few possible approaches:

• Have a list of DICOM providers in the global configuration file. It requires manual intervention on installing a new plugin (this piece of information is fixed and plugin-dependant), but requires no modification to the SDK or existing plugins. Added: If no query provider was listed here, then it is assumed that all providers are DICOM.
• Add a new method to QueryInterface with a signature similar to bool providesDICOM(), thus leaving the flag defined by the plugin itself, as it's meant to be. Unfortunately, this demands a change to the SDK, as well as existing plugins.
• A mid-term: Have a flag in the plugin's local configuration file. The plugin can force it to a constant value and the core can read these files too. Only requires modifying the plugin controller and our DICOM providers.

Have any additional ideas? What do you think?

[Enet4]

I will take the first approach while keeping the same behaviour if no specific configuration was given.

Have a list of DICOM providers in the global configuration file. It requires manual intervention on installing a new plugin (this piece of information is fixed and plugin-dependant), but requires no modification to the SDK or existing plugins. If no query provider was listed here, then it is assumed that all providers are DICOM.

[bastiao]

After the discussion, and agreement, I will only highlight the points for the record:
if there are no defined settings, all the plugins will be assumed as DICOM.
Next major jump, we may think to adopt SDK changes.

[Enet4]

The new configuration property dim-provider allows us to specify which query sources are DICOM. All that's left to do is rely on this internally for certain services (DICOM network services, /dump, possibly others).

[Enet4]

#342 Makes it so that Dicoogle /search and /dump services acknowledge DICOM sources only. To complete this issue, we would need to integrate this to the remaining services (DICOM query/retrieve comes to mind).

[Enet4]

I have decided to close this as resolved by #342 and delegate the application of DIM provider information to DICOM services in #513.